[Bug ld/2290] New: ld searches for implicit shared library dependencies in the wrong order (in particular, differently from linux's ld.so)

[jhbrown at itasoftware dot com]

When ld looks up dependent libraries, it searches a variety of
locations, with the final two sets being first, the system directories
/lib and /usr/lib; and second and finally, in directories listed in
/etc/ld.so.conf This order is documented in the info pages, see [1]

On GNU/Linux (Fedora core 3), ld.so will look for shared libraries in
a variety of places, with the final two places searched being, first,
entries cached in /etc/ld.so.cache; and second (and finally), /lib and
then /usr/lib.  This order is documented in the man page, see [2]

This means that unless you explicitly use the -rpath-link flag to ld
to replicate the contents of /etc/ld.so.conf, the directories searched
will be different at link-time and run-time.  This effect is
demonstrated by the sequence of commands at the bottom of this
message, see [3]   These commands are tailored for x86_64; you may need
to tweak them if you're on a 32-bit-only box.

I believe ld is doing the wrong thing here (although it is
*documentedly* doing the wrong thing;) it should favor paths in
/etc/ld.so.conf ahead of hard-coded system paths.

At the bottom of this email is a sequence of commands that illustrates
this conflicting behavior on my Fedora core 3 x86_64 box.  Here's the
most interesting part of the output from running them.

------------------------------------------------------------
1 sh-3.00#  gcc -Xlinker -verbose foo.c -o foo -lgnome-2 2>&1 | grep libxml2
2 libxml2.so.2 needed by /usr/lib64/libgnomevfs-2.so.0
3 found libxml2.so.2 at /usr/lib64/libxml2.so.2  
4 sh-3.00#  ldd foo | grep libxml2
5         libxml2.so.2 => /usr/lib/test/libxml2.so.2 (0x00002aaaac16b000)
6 sh-3.00#  LD_DEBUG=libs ./foo 2>&1 | grep libxml2
7      24661:     find library=libxml2.so.2 [0]; searching
8      24661:       trying file=/usr/lib/test/libxml2.so.2
9      24661:     calling init: /usr/lib/test/libxml2.so.2
10     24661:     calling fini: /usr/lib/test/libxml2.so.2 [0]
------------------------------------------------------------

Note that at line 3, the linker reports finding libxml2 at
/usr/lib64/libxml2, while at line 5, ldd finds it in /usr/lib/test/ As
another check, lines 8-10 show that ld.so also finds it in
/usr/lib/test

Obviously, if I have different versions of the library in a custom
path and a system path, I may have real trouble at link-time or
run-time.

Thanks for your time,
Jeremy



------------------------------------------------------------
[1]:  From the GNU ld info page documentation on -rpath-link:

       7. The default directories, normally `/lib' and `/usr/lib'.

       8. For a native linker on an ELF system, if the file
          `/etc/ld.so.conf' exists, the list of directories found in
          that file.

------------------------------------------------------------
[2]:  From the GNU/Linux man page on ld.so (Fedora):

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

------------------------------------------------------------
[3] The following sequence of commands demonstrates the problem.
    It relies on the implicit dependency of libgnome-2 on libxml2.  
    It needs to be run as root, because it adjusts (and then resets) 
    ld.so.conf.

 mkdir -p /usr/lib/test
 echo '/usr/lib/test' | cat - /etc/ld.so.conf > /etc/ld.so.conf.new
 mv /etc/ld.so.conf /etc/ld.so.conf.old
 mv /etc/ld.so.conf.new /etc/ld.so.conf
 cd /usr/lib/test
 cp -s /usr/lib64/libxml2.* .
 ldconfig
 cd /tmp
 echo 'int main(int argc, char **argv) { return 0;}' > foo.c
 gcc -Xlinker -verbose foo.c -o foo -lgnome-2 2>&1 | grep libxml2
 ldd foo | grep libxml2
 LD_DEBUG=libs ./foo 2>&1 | grep libxml2
 gcc -Xlinker -rpath-link /usr/lib/test -Xlinker -verbose foo.c -o foo -lgnome-2
2>&1 | grep libxml2
 ldd foo | grep libxml2
 mv /etc/ld.so.conf.old /etc/ld.so.conf
 rm -r /usr/lib/test
 ldconfig

-- 
           Summary: ld searches for implicit shared library dependencies in
                    the wrong order (in particular, differently from linux's
                    ld.so)
           Product: binutils
           Version: 2.15
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
        AssignedTo: unassigned at sources dot redhat dot com
        ReportedBy: jhbrown at itasoftware dot com
                CC: bug-binutils at gnu dot org
 GCC build triplet: x86_64-redhat-linux
  GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux


http://sourceware.org/bugzilla/show_bug.cgi?id=2290

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.