[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#655711: ldconfig makes system loader /lib/ld-linux.so.2 to be linked to 3rd party loader in /lib directory



Hi,

Venkatesh_Prasad@McAfee.com wrote:

> Version: 2.13-0ubuntu13

Can you reproduce this with libc-bin from Debian squeeze or sid?  If
not, this is not the place to report it.  Ubuntu bugs are tracked on
launchpad.

> System having installed with some 3rd party loaders (ld-<name>.so.x)
> in /lib directory. With these loaders present if we run ldconfig,
> its removing the system loader symbolic link ld-linux.so.2 in /lib
> directory from /lib/i286-linux-gnu/ld-2.13.so and creating the
> symbolic link to one of the 3rd party loaders(in my case link to
> ld-nails.so.2) present in /lib directory.

Is this a regression?  Did previous versions ignore ld-nails.so.2 for
some reason?

It looks like what is happening is that ld-nails.so.2 encodes a SONAME
of ld-linux.so.2 (you can check with "readelf -d /lib/ld-nails.so.2 |
grep SONAME"), so ldconfig makes a symlink to it.  The dynamic loader
is considered a shared library just like /lib/lib* and has been so at
least since ldconfig was added to glibc in 1999.

If one wants a private library, so as not to have ldconfig
automatically creating symlinks to it, it cannot go straight in /lib
or anywhere else on the library path but should be placed elsewhere
(for example somewhere in /opt).  Alternatively, if this is a public
library but is not meant to provide the ld-linux.so.2 interface, it
should encode a different soname.

Hope that helps,
Jonathan



Reply to: