Bug 525002
Summary: | Busticated libcurl.so has missing symbols | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Valdis Kletnieks <valdis.kletnieks> |
Component: | curl | Assignee: | Kamil Dudka <kdudka> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | cweyl, gczarcinski, james.antill, kdudka, sundaram |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | 7.19.6-10.fc12 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-09-27 15:42:44 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Valdis Kletnieks
2009-09-22 22:46:14 UTC
Thanks for your report! It seems to be related to bug 523796. There are no API/ABI changes in libcurl itself I know about. Could you please try to update libssh2 if it resolves the linking issue? Sorry, unable to easily cleanly update libssh2: # yum update 'libssh2*' Loaded plugins: dellsysidplugin2, downloadonly, refresh-packagekit, refresh-updatesd Setting up Update Process Resolving Dependencies There are unfinished transactions remaining. You might consider running yum-complete-transaction first to finish them. --> Running transaction check ---> Package libssh2.i686 0:1.2-2.fc12 set to be updated --> Processing Dependency: libssl.so.10 for package: libssh2-1.2-2.fc12.i686 --> Processing Dependency: libcrypto.so.10 for package: libssh2-1.2-2.fc12.i686 ---> Package libssh2.x86_64 0:1.2-2.fc12 set to be updated ---> Package libssh2-devel.x86_64 0:1.2-2.fc12 set to be updated --> Running transaction check --> Processing Dependency: libcrypto.so.8 for package: opensc-0.11.8-2.fc12.i586 --> Processing Dependency: libcrypto.so.8 for package: openldap-2.4.16-4.fc12.i686 --> Processing Dependency: libssl.so.8 for package: openldap-2.4.16-4.fc12.i686 --> Processing Dependency: openssl = 0.9.8k-7.fc12 for package: openssl-devel-0.9.8k-7.fc12.x86_64 --> Processing Dependency: libcrypto.so.8()(64bit) for package: x3270-3.3.6-9.fc12.x86_64 --> Processing Dependency: libcrypto.so.8()(64bit) for package: libwvstreams-4.6-4.fc12.x86_64 (and literally 75 other packages still linked against the old release of openssl) Looks like I'll have to see if I can 'rpm --force' it on, but that will have to wait till morning when I'm more awake... That's why we like to play with rawhide :-) It is not necessary to install the package to system to test its linking state. You can download libssh2-1.2 RPM and unpack to /tmp with rpm2cpio/cpio. Then you can force the libssh2.so to dynamic linker: $ LD_PRELOAD=/tmp/usr/lib64/libssh2.so ldd /usr/bin/curl But if your system lacks up2date SSL libraries, you will most likely run into another linking problem this way. diff -u -r1.116 curl.spec --- curl.spec 22 Sep 2009 03:52:18 -0000 1.116 +++ curl.spec 23 Sep 2009 18:01:31 -0000 @@ -18,8 +18,9 @@ BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildRequires: autoconf BuildRequires: groff +BuildRequires: libssh2-devel >= 1.2 BuildRequires: openssh-server openssh-clients -BuildRequires: pkgconfig, libidn-devel, zlib-devel, libssh2-devel +BuildRequires: pkgconfig, libidn-devel, zlib-devel BuildRequires: nss-devel >= 3.11.7-7, openldap-devel, krb5-devel BuildRequires: stunnel Requires: libcurl = %{version}-%{release} Proposed patch for curl to pull-in the requested version of libssh2 before updating itself and thus doesn't break the linkage. Note we have no problem in the fresh F-12 installation (neither in F-12 beta) since the versions are matching in the default setup. Chris, what do you think about the fix? I admit not understanding why it's a buildrequires on the -devel RPM rather than a Requires: on the shared lib. (note that I ran into this situation because there wasn't a Requires on the shared lib). In that case, what prevents it from building on a RedHat box that has the right -devel installed, and then hosing up when it gets to my laptop? (If the answer is 'rpmbuild automagically injects a 'Requires:' for the shared lib' or something, then I'm OK on it). Kind of. I am not an RPM guru to explain how exactly the dependency resolving works. You can try the patch yourself and see what happens. What precisely do you mean by "Requires: on the shared lib"? If you mean .so dependency, I am in opposite to use it in this particular case: http://fedoraproject.org/wiki/Packaging/Guidelines#Explicit_Requires OK, I read the "explicit requires" stuff, and this text: "We generally rely on rpmbuild to automatically add dependencies on library SONAMEs." and the "BuildRequires" doc a bit further down, seem to imply that we *need* the BuildRequires so we *link* the binary against recent-enough libs - and then 'rpmbuild' will add the Requires itself (so 'rpm -q --requires' ends up listing the correct .so automagically. So yeah, looks like that BuildRequires patch will DTRT. Thanks for review! I've just built it as curl-7.19.6-9.fc12. Please leave here a note if the problem persists. Problem not fixed. # rpm -q curl curl-7.19.6-9.fc12.i686 # yum There was a problem importing one of the Python modules required to run yum. The error leading to this problem was: /usr/lib/libcurl.so.4: undefined symbol: libssh2_knownhost_init [snipped] (In reply to comment #9) > Problem not fixed. > > # rpm -q curl Please report the version of libssh2 (and perhaps libcurl) instead. How exactly did you update the curl package? I am not able to reproduce it myself. #rpm -q libcurl libssh2 libcurl-7.19.6-9.fc12.i686 libssh2-1.0-3.fc12.i686 I downloaded the latest curl and libcurl from Koji. Well, the fix from curl-7.19.6-9.fc12 does not solve anything as the output of 'rpm -qR libcurl' is obviously incomplete. I've just committed fix to CVS. The new build should be available later today. Fixed in libcurl-7.19.6-10.fc12. $ rpm -q libcurl libcurl-7.19.6-10.fc12.x86_64 $ rpm -qR libcurl | grep ssh libssh2 >= 1.2 libssh2.so.1()(64bit) This has recently affected F11, if you are using an F12+ yum (or anything else which require pycurl, I'd guess ... but breaking yum has it's own problems :). Anyway, this fixed it for me: wget http://download.fedora.redhat.com/pub/fedora/linux/updates/11/x86_64/libssh2-1.2.2-4.fc11.x86_64.rpm http://download.fedora.redhat.com/pub/fedora/linux/updates/11/x86_64/libssh2-1.2.2-4.fc11.i586.rpm sudo rpm -Uvh libssh2-1.2.2-4.fc11.i586.rpm libssh2-1.2.2-4.fc11.x86_64.rpm And (In reply to comment #15) > This has recently affected F11, if you are using an F12+ yum (or anything else > which require pycurl, I'd guess ... but breaking yum has it's own problems :). As does running F-12+ yum on F-11 :) Is there something specific here that would have prevented this? Some sort of rpm metadata indicating a newer libssh2 is needed (probably in the package owning libcurl, I expect)? As you can see, the bug is closed and the explicit dependency added into F-12 libcurl half year ago. F-11 libssh2 package was not intended to rebase and break ABI, at least I am not aware of any discussion wrt. this topic. (In reply to comment #17) > As you can see, the bug is closed and the explicit dependency added into F-12 > libcurl half year ago. F-11 libssh2 package was not intended to rebase and > break ABI, at least I am not aware of any discussion wrt. this topic. Right, I see that. So why did you bring it up over in bug 561491 then? Good point, the bug was already triggered by libssh2-1.2.2-4.fc11 (released 2010-01-20). Nevertheless bug 561491 has the same flaw. You again thrown F-11 rebase without any comment on that, and without any discussion with owners of affected packages. And sorry for the confusion! I was following the ChangeLog of F-11 libssh2, which is completely misleading. From the last 8 ChangLog entries are 4 of them _fraud_. I have never seen anything like that... In reply to comment #16, yes I realize that (hopefully) not many people are going to have a broken yum ... but anyone could have a broken pycurl. If you can do it a simple "python -c 'import pycurl'" in the %check section should have caught this. Sure, you can just run 'yum update libcurl' and the disaster is done. There is not much I can do when the libssh2 update is already in stable. I can add the explicit dependency for new libssh2 and release F-11 update because of that. But it does not solve the already broken installation, does it? |