Results 1 to 2 of 2
Enjoy an ad free experience by logging in. Not a member yet? Register.
- Join Date
- Feb 2008
How does LD find /lib/tls/i686/cmov?
/lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.4' not found
I look at /lib/tls/i686/cmov/libc.so.6 with objdump (it doesn't work with nm - (?)), and I see:
debian:tools$ objdump -p /lib/tls/i686/cmov/libc.so.6
13 0x00 0x0d696913 GLIBC_2.3
14 0x00 0x09691972 GLIBC_2.3.2
15 0x00 0x09691973 GLIBC_2.3.3
16 0x00 0x09691974 GLIBC_2.3.4
And no GLIBC_2.4.
So... I know I'm going to have to upgrade libc (although I've seen some pretty dire warnings against doing so). However, I'm still just trying to figure out where this is coming from!
debian:tools$ echo $LD_LIBRARY_PATH
not /lib/tls/i686/cmov - and /etc/ld.so.conf.d contains one file whose contents also don't include this mysterious /lib/tls/i686/cmov:
debian:ld.so.conf.d$ cat i486-linux-gnu.conf
# Multiarch support
Where the heck is "/lib/tls/i686/cmov" coming from? Is this just some "magic" inside ld.so? I don't see it documented anywhere - the man page says it should be looking in the following order:
Using the environment variable LD_LIBRARY_PATH
(LD_AOUT_LIBRARY_PATH for a.out programs). Except if the exe‐
cutable is a setuid/setgid binary, in which case it is ignored.
o From the cache file /etc/ld.so.cache which contains a compiled
list of candidate libraries previously found in the augmented
o In the default path /usr/lib, and then /lib.
I see a /lib/libc.so.6, but it's not a symlink to /lib/tls/i686/cmov...
- Join Date
- Feb 2010
I know that this post is a bit outdated but just for the sake of those who may be interested, let me reply to this post.
The answer is that ld.so obtains tls information from ld.so.cache.
If you look at man page for ld-linux.so, you will see how ld finds the information.
As you posted, followings are the descriptions from man page.
The shared libraries needed by the program are searched for in various places:
o (ELF only) Using the DT_RPATH dynamic section attribute of the binary if present
and DT_RUNPATH attribute does not exist. Use of DT_RPATH is deprecated.
o Using the environment variable LD_LIBRARY_PATH. Except if the executable is a
set-user-ID/set-group-ID binary, in which case it is ignored.
o (ELF only) Using the DT_RUNPATH dynamic section attribute of the binary if
o From the cache file /etc/ld.so.cache which contains a compiled list of candidate
libraries previously found in the augmented library path. If, however, the
binary was linked with -z nodeflib linker option, libraries in the default
library paths are skipped.
o In the default path /lib, and then /usr/lib. If the binary was linked with -z
nodeflib linker option, this step is skipped.
Normally, we don't care about LD_LIBRARY_PATH so that means we go straight to ld.so.cache.
So for loader cache, loader parses ld.so.cache and it finds the entry for /lib/tls/i686/cmov there. (We can also try to do the same thing to verify)
For your reference, look for ldconfig.c and cache.c in loader source code.
Here is cache_file struct format.
char magic[sizeof CACHEMAGIC - 1];
unsigned int nlibs;
struct file_entry libs;
Basically, we just need to loop through until we find what we need for libc as an example.
In fact, it is little bit more involved in that loader checks a few more and applies different logic to retrieve the right ones but this should give you at least some insight into loader.
So I think that loader finds the appropriate entry from ld.so.cache in your case.