On 08/03/2016 06:40 PM, Chris Adams wrote:> Once upon a time, Alice Wonder <alice at domblogger.net> said: >> [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) > > Here is your problem - unless you specify an LD_LIBRARY_PATH, you are > getting the mock root installed libcurl, not your newly-built libcurl. >So when building curl, it links curl against the libcurl in the buildroot and not against the libcurl it just compiled? No other packages I know of do that. I've built a love of packages against LibreSSL (I really like it) and ldd on the resulting binaries and libraries *always* point to the LibreSSL library - even when openssl-libs is installed in the buildroot. It seems to me to be a bug if curl requires a bootstrap build in order to change what libraries the binary links against but I will try that.
Once upon a time, Alice Wonder <alice at domblogger.net> said:> So when building curl, it links curl against the libcurl in the > buildroot and not against the libcurl it just compiled? > > No other packages I know of do that.No, that is not what it does. If you posted the full ldd output like I asked, rather than grepping out bits, you'd see it loading the system libcurl. When you run ldd against an arbitrary binary, ldd uses the system directories to resolve dependencies. The libcurl you just built is not in any of those directories, but the system libcurl (that is linked against libssh2, which pulls in libssl/libcrypto) is. The dynamic linker uses the library it can find. If you want to use a different library, you have to specify the path. If you look at curl.spec, you will see it set LD_LIBRARY_PATH before running tests, so that it gets its newly-built libcurl dependency. There is absolutely nothing magic or broken in curl, its build setup, or mock. -- Chris Adams <linux at cmadams.net>
On 08/03/2016 06:57 PM, Chris Adams wrote:> Once upon a time, Alice Wonder <alice at domblogger.net> said: >> So when building curl, it links curl against the libcurl in the >> buildroot and not against the libcurl it just compiled? >> >> No other packages I know of do that. > > No, that is not what it does. If you posted the full ldd output like I > asked, rather than grepping out bits, you'd see it loading the system > libcurl. > > When you run ldd against an arbitrary binary, ldd uses the system > directories to resolve dependencies. The libcurl you just built is not > in any of those directories, but the system libcurl (that is linked > against libssh2, which pulls in libssl/libcrypto) is. The dynamic > linker uses the library it can find. > > If you want to use a different library, you have to specify the path. > If you look at curl.spec, you will see it set LD_LIBRARY_PATH before > running tests, so that it gets its newly-built libcurl dependency. > > There is absolutely nothing magic or broken in curl, its build setup, or > mock. >Okay I think I got it. You are saying that ldd is recursive and since curl links against libcurl running ldd on the curl binary also results in the libraries that it libcurl on the system is linked against. I didn't realize ldd was recursive. I may have known that at one point (been using linux since MK Linux DR3 and building RPMs since 1999), but have a head injury results in memory problems with pieces of knowledge I don't frequently use. Thank you, that makes sense.