Bug 525002 - Busticated libcurl.so has missing symbols
Summary: Busticated libcurl.so has missing symbols
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: curl
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kamil Dudka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-22 22:46 UTC by Valdis Kletnieks
Modified: 2010-03-29 07:59 UTC (History)
5 users (show)

Fixed In Version: 7.19.6-10.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-27 15:42:44 UTC


Attachments (Terms of Use)

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?


Note You need to log in before you can comment on or make changes to this bug.