Re: ldd and library dependency
- From: Frank Hamersley <terabitemightbe@xxxxxxxxxxx>
- Date: Tue, 14 Mar 2006 02:51:41 GMT
Laurenz Albe wrote:
Frank Hamersley <terabitemightbe@xxxxxxxxxxx> wrote:
My issue is similar only in that library selection is not as I would expect in that libraries from /lib/tls are selected by ldd rather than the /lib instances that I require.
As I did not know the answer right away, I investigated and here is the
result, which I get from
which I found with a web search.
Some shared libraries contain an OS ABI tag, that is a section that
tells the dynamic loader which kernel version is required to run this
On RedHat systems you can see it with
eu-readelf -n /lib/libm-2.3.2.so
on other systems you can use
objdump -s -j .note.ABI-tag /lib/tls/libm-2.3.2.so
to get a slightly less readable version (bytes 21, 25, and 29 from
the section contain the version numbers).
On my RedHat system, there are some libraries that have versions in
/lib, /lib/i686 and /lib/tls (which stands for Thread-Local Storage),
among them libc, and the OS ABI versions of the libraries increase in
that order (2.2.5, 2.4.1 and 2.4.20, respectively).
The loader chooses the library with the highest ABI version less or equal
to the kernel version.
If for some reason you need to use an older ABI version (that is, load the
library form one of the other directories), you can use the environment
variable LD_ASSUME_KERNEL to tell the loader which kernel version to assume.
So if you insist in loading from /lib (I hope that you have good reasons),
you should set LD_ASSUME_KERNEL to something between 2.2.5 and 2.4.0
(if the numbers on your system are the same as on my system).
Brilliant treatise Albe - on investigation this describes my issue down to a tee! You can confirm the /etc/ld.so.cache contents with the ldconfig -p command which exposes the ABI numbers too. Furthermore it shows the various paths that ldconfig scans when building a new cache.
For instance the libpthread was one of my problem libs ...
[root@TERASERV ~]# ldconfig -p | fgrep libpthread
libpthread.so.0 (libc6, hwcap: 0x8000000000000000, OS ABI: Linux 2.4.20) => /lib/tls/libpthread.so.0
libpthread.so.0 (libc6, hwcap: 0x8000000000000, OS ABI: Linux 2.4.1) => /lib/i686/libpthread.so.0
libpthread.so.0 (libc6, OS ABI: Linux 2.2.5) => /lib/libpthread.so.0
The switch in ldconfig that shows how the tls and i686 paths are discovered seems to be ...
-n Only process directories specified on the command line. Don't process the trusted directories (/lib and /usr/lib) nor those specified in /etc/ld.so.conf. Implies -N.
What it doesn't quite spell out but quite reasonably does is search all subdirectories in the "trusted" paths and include them in the cache. Thereafter the ABI behaviour kicks and and given my CentOS kernel is 2.6 the 2.4.20 version gets the nod! Interestingly this was the old RH7.3 kernel version I was running so I expect this library might have been in use back then. If so, it worked OK on that kernel but not this one!
As I expected I should prolly .rpm in later versions of the tls and i686 libraries from the CentOS yum site and see where that leads! Will report here then.
- Re: ldd and library dependency
- From: FrankHamersley
- Re: ldd and library dependency
- Prev by Date: Re: Installing Linux from within Linux?
- Next by Date: Re: Installing Linux from within Linux?
- Previous by thread: Re: ldd and library dependency
- Next by thread: Re: ldd and library dependency