Find the answer to your Linux question:
Results 1 to 2 of 2
I'm running Debian Lenny/Sid, BTW. More and more, I've been (forced to) download binary-only (no source code available) software for my linux system (for example, Flash and the Android SDK). ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Feb 2008
    Posts
    4

    How does LD find /lib/tls/i686/cmov?


    I'm running Debian Lenny/Sid, BTW. More and more, I've been (forced to) download binary-only (no source code available) software for my linux system (for example, Flash and the Android SDK). The problem is, it's all failing lately with:

    /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
    GLIBC_2.2.6
    14 0x00 0x09691972 GLIBC_2.3.2
    GLIBC_2.3
    15 0x00 0x09691973 GLIBC_2.3.3
    GLIBC_2.3.2
    16 0x00 0x09691974 GLIBC_2.3.4
    GLIBC_2.3.3
    ...

    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!

    LD_LIBRARY_PATH contains:

    debian:tools$ echo $LD_LIBRARY_PATH
    /usr/local/Trolltech/Qt-4.3.4/lib:/usr/local/lib

    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$ ls
    i486-linux-gnu.conf
    debian:ld.so.conf.d$ cat i486-linux-gnu.conf
    # Multiarch support
    /lib/i486-linux-gnu
    /usr/lib/i486-linux-gnu

    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
    library path.

    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...

  2. #2
    Just Joined!
    Join Date
    Feb 2010
    Posts
    1
    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
    present.

    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.

    struct cache_file
    {
    char magic[sizeof CACHEMAGIC - 1];
    unsigned int nlibs;
    struct file_entry libs[0];
    };

    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.

    HTH.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •