On 08/03/2016 07:53 PM, Alice Wonder wrote:
On 08/03/2016 06:57 PM, Chris Adams wrote:
Once upon a time, Alice Wonder alice@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.
From google search, it looks like not all versions of ldd are recursive.
The symptoms of this problem though suddenly make sense if it is (ldd in buildroot on curl binary different from library)