Description of problem: After upgrading libcurl, 'yum' died with this error message: There was a problem importing one of the Python modules required to run yum. The error leading to this problem was: /usr/lib64/libcurl.so.4: undefined symbol: libssh2_knownhost_init Please install a package which provides this module, or verify that the module is installed correctly. It's possible that the above module doesn't match the current version of Python, which is: 2.6.2 (r262:71600, Jul 30 2009, 17:08:54) [GCC 4.4.1 20090725 (Red Hat 4.4.1-3)] Reverting libcurl back to libcurl-7.19.5-9.fc12 fixed it. It looks like somebody changed the API, but failed to bump the .so number to .so.5. As a result, installing the new libcurl "succeeded" because python-pycurl has an explicit 'Requires: libcurl.so.4()(64bit)' attached to it, and then everything that used python-pycurl died a horrid death because there wasn't a matching update for python-pycurl installed. Version-Release number of selected component (if applicable): libcurl-7.19.6-8.fc12.i686 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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?