On 08/03/2016 06:13 PM, Chris Adams wrote:> Once upon a time, Alice Wonder <alice at domblogger.net> said: >> Something in the curl build will always link the binary against >> OpenSSL if the openssl-lib package is present, and will always link >> the library against OpenSSL if any TLS option is enabled in the >> configure. > > No, it doesn't. You can see this by looking at the RPM dependencies; at > least on CentOS 7 and Fedora 23, they don't depend on libssl.so at all. > If either curl or libcurl.so were linked against libssl.so, the RPM > would require it. > > I just tried building the CentOS 7 RPM of curl, changing the SPEC to > remove the libssh2 settings, and I got a curl and libcurl that do not in > any way depend on libssl. It is most definitely libssh2.so that > requires libssl.so. > > If you want help, you need to stop repeating your claims and show some > actual commands run, output, versions, etc. >[alice at pern ~]$ ldd /usr/bin/curl |grep crypto libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f4524390000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f45234ca000) [alice at pern ~]$ rpm -qf /lib64/libcrypto.so.10 openssl-libs-1.0.1e-51.el7_2.5.x86_64 [alice at pern ~]$ That's with stock CentOS packages
On 08/03/2016 06:17 PM, Alice Wonder wrote: *snip*> > [alice at pern ~]$ ldd /usr/bin/curl |grep crypto > libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f4524390000) > libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f45234ca000) > [alice at pern ~]$ rpm -qf /lib64/libcrypto.so.10 > openssl-libs-1.0.1e-51.el7_2.5.x86_64 > [alice at pern ~]$ > > That's with stock CentOS packagesThat is also what I get when building curl in mock with exlude=openssl* and test the built binary with ldd - even with libssh and openssh built against LibreSSL (which uses libcrypto.so.37 instead of .10)
Once upon a time, Alice Wonder <alice at domblogger.net> said:> [alice at pern ~]$ ldd /usr/bin/curl |grep crypto > libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f4524390000) > libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f45234ca000)What do the following show: ldd /usr/bin/curl ldd /usr/lib64/libcurl.so.4 ldd /usr/lib64/libssh2.so.1 I can only guess you don't have the libssh2 you think you have. I just replaced curl/libcurl on a CentOS 7 system with my version built without ssh2 support: $ ldd /usr/bin/curl linux-vdso.so.1 => (0x00007fff4b9fc000) libcurl.so.4 => /lib64/libcurl.so.4 (0x00007f001623f000) libssl3.so => /lib64/libssl3.so (0x00007f0015ffd000) libsmime3.so => /lib64/libsmime3.so (0x00007f0015dd5000) libnss3.so => /lib64/libnss3.so (0x00007f0015aaf000) libnssutil3.so => /lib64/libnssutil3.so (0x00007f0015883000) libplds4.so => /lib64/libplds4.so (0x00007f001567e000) libplc4.so => /lib64/libplc4.so (0x00007f0015479000) libnspr4.so => /lib64/libnspr4.so (0x00007f001523b000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f001501e000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f0014e1a000) libz.so.1 => /lib64/libz.so.1 (0x00007f0014c04000) libc.so.6 => /lib64/libc.so.6 (0x00007f0014842000) libidn.so.11 => /lib64/libidn.so.11 (0x00007f001460f000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f00143c3000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f00140dd000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f0013eab000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f0013ca7000) liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007f0013a97000) libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007f0013844000) librt.so.1 => /lib64/librt.so.1 (0x00007f001363b000) /lib64/ld-linux-x86-64.so.2 (0x00007f00164a6000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f001342c000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f0013228000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f001300d000) libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f0012df0000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f0012bca000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f0012993000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f0012732000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f001250c000) libfreebl3.so => /lib64/libfreebl3.so (0x00007f0012309000) No libssl.so, no libcrypto.so. -- Chris Adams <linux at cmadams.net>
On 08/03/2016 06:30 PM, Chris Adams wrote:> Once upon a time, Alice Wonder <alice at domblogger.net> said: >> [alice at pern ~]$ ldd /usr/bin/curl |grep crypto >> libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f4524390000) >> libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f45234ca000) > > What do the following show: > > ldd /usr/bin/curl > ldd /usr/lib64/libcurl.so.4 > ldd /usr/lib64/libssh2.so.1 > > I can only guess you don't have the libssh2 you think you have.It's worse than I thought. I just very carefully went through the mock build root. openssl-libs is indeed not even installed. There is no libcrypto.so.10 installed in the mock build root. But the binary built by mock still links to it. So it is linking against a library not even in the mock build root. That shouldn't happen. [alice at pern root]$ pwd /var/lib/mock/awel-7-curl-x86_64/root (to show I'm in the build root - I put exit 1 in %check) [alice at pern root]$ ls usr/lib64/ |grep crypto libcrypto.so.38 libcrypto.so.38.0.0 libk5crypto.so.3 libk5crypto.so.3.1 [alice at pern root]$ ldd builddir/build/BUILDROOT/curl-7.29.0-26.el7_2.awel.libre.0.x86_64/usr/bin/curl |grep crypto libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fb6e00a5000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fb6df3e8000) [alice at pern root]$