Package: libcurl3
Version: 7.42.1-2+b1
Severity: important
File: libcurl
Dear Maintainer,
[red alert - I've recently done a dist upgrade from old-stable to stable]
It looks as though libcurl.so.4 has calls in it to SSLv3_client_method
which it tries to resolve against libssl.so.1.0.0 (which knows nothing
about any SSLv3_* stuff) whereas it probably should be resoving against
libgnutls-openssl.so.27.0.2. My copy certainly contains those strings,
but its symbol table is stripped so I can't say for sure .. however
libgnutls-openssl.a DOES contain the symbol 000007f0 T SSLv3_client_method
so it's pretty well certain that the .so does as well.
This manifests for me only when running cmake
% cmake .
cmake: relocation error: /usr/lib/i386-linux-gnu/libcurl.so.4:
symbol SSLv3_client_method, version OPENSSL_1.0.0 not defined in
file libssl.so.1.0.0 with link time reference
and freetuxtv
% freetuxtv
freetuxtv: relocation error: /usr/lib/i386-linux-gnu/libcurl.so.4:
symbol SSLv3_client_method, version OPENSSL_1.0.0 not defined in
file libssl.so.1.0.0 with link time reference
and presumably other users of curl.so.4.
It was sort-of cured by preloading libgnutls-openssl.so.27.0.2.so for a
while after I tried recompiling the debian-stable source of curl,
adding -lgnutls-openssl to the LIBS list wherever I could, but I
couldn't get ths hared library to point the right way so I've tried
upgrading to the unstable set of curl stuff instead, and now
% setenv LD_PRELOAD /usr/lib/i386-linux-gnu/libgnutls-openssl.so
doesn't help. Yes, libcurl.so.4 is pointing at .so.4.3.0:
% ll /usr/lib/i386-linux-gnu/libcurl.so.4
lrwxrwxrwx 1 root 16 Jun 3 12:32 /usr/lib/i386-linux-gnu/libcurl.so.4 ->
libcurl.so.4.3.0
% ll /usr/lib/i386-linux-gnu/libcurl.so.4.3.0
-rw-r--r-- 1 root 538168 Jun 3 12:32 /usr/lib/i386-linux-gnu/libcurl.so.4.3.0
and indeed, it tries to resolve against libssl.so.1.0.0, which can't help
it:
% ldd /usr/lib/i386-linux-gnu/libcurl.so.4 | grep ssl
libssl.so.1.0.0 => /usr/lib/i386-linux-gnu/i686/cmov/libssl.so.1.0.0
(0xb7570000)
So, what's up? Do you know? My experience of debian maintainers is
that typically you don't do debugging, and just wait around in case
somebody solves it by accident or it gets solved in some upstream
upgrade years later, or the package goes away. I don't have any
sympathy ... debugging is what the job entails, and upstream will think
the same. You caused it, you fix it. I'm willing to help you, so press
the email button and I'll apply my C skills and you can apply your
configuration knowhow, and we should be able to figure it out.
How on Earth does libcurl.so.4.3.0 end up pointing at libssl1.0.0? Is
that a weak/strong symbols thing?
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: 8.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'unstable'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.16.7-betty (PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages libcurl3:i386 depends on:
ii libc6 2.19-18
ii libcomerr2 1.42.12-1.1
ii libgssapi-krb5-2 1.12.1+dfsg-19
ii libidn11 1.29-1+b2
ii libk5crypto3 1.12.1+dfsg-19
ii libkrb5-3 1.12.1+dfsg-19
ii libldap-2.4-2 2.4.40+dfsg-1
ii librtmp1 2:2.4~20150315.gita107cef9b-dmo1
ii libssh2-1 1.4.3-4.1
ii libssl1.0.0 1.0.2-1
ii zlib1g 1:1.2.8.dfsg-2+b1
Versions of packages libcurl3:i386 recommends:
ii ca-certificates 20141019
libcurl3:i386 suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
