Bug 525002

Summary: Busticated libcurl.so has missing symbols
Product: [Fedora] Fedora Reporter: Valdis Kletnieks <valdis.kletnieks>
Component: curlAssignee: Kamil Dudka <kdudka>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: 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
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:

Comment 1 Kamil Dudka 2009-09-23 04:38:45 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?

Comment 2 Valdis Kletnieks 2009-09-23 05:31:12 UTC
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...

Comment 3 Kamil Dudka 2009-09-23 05:45:56 UTC
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.

Comment 4 Kamil Dudka 2009-09-23 18:11:00 UTC
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?

Comment 5 Valdis Kletnieks 2009-09-23 19:19:29 UTC
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).

Comment 6 Kamil Dudka 2009-09-23 19:35:57 UTC
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

Comment 7 Valdis Kletnieks 2009-09-23 20:52:08 UTC
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.

Comment 8 Kamil Dudka 2009-09-26 08:55:38 UTC
Thanks for review! I've just built it as curl-7.19.6-9.fc12. Please leave here a note if the problem persists.

Comment 9 Rahul Sundaram 2009-09-27 12:30:03 UTC
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]

Comment 10 Kamil Dudka 2009-09-27 13:07:50 UTC
(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.

Comment 11 Rahul Sundaram 2009-09-27 15:08:14 UTC
#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.

Comment 12 Kamil Dudka 2009-09-27 15:14:42 UTC
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.

Comment 13 Kamil Dudka 2009-09-27 15:42:44 UTC
Fixed in libcurl-7.19.6-10.fc12.

Comment 14 Kamil Dudka 2009-09-27 15:45:35 UTC
$ rpm -q libcurl
libcurl-7.19.6-10.fc12.x86_64

$ rpm -qR libcurl | grep ssh
libssh2 >= 1.2
libssh2.so.1()(64bit)

Comment 15 James Antill 2010-03-28 15:50:49 UTC
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

Comment 16 Chris Weyl 2010-03-28 19:33:01 UTC
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)?

Comment 17 Kamil Dudka 2010-03-28 19:50:30 UTC
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.

Comment 18 Chris Weyl 2010-03-28 20:55:39 UTC
(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?

Comment 19 Kamil Dudka 2010-03-28 21:18:33 UTC
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...

Comment 20 James Antill 2010-03-29 04:42:12 UTC
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.

Comment 21 Kamil Dudka 2010-03-29 07:59:37 UTC
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?