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@xxxxxxxxxxxxxx> 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)
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
