This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
ldconfig search order
- To: <glibc-linux at ricardo dot ecn dot wfu dot edu>
- Subject: ldconfig search order
- From: "Carlos Pita" <cpita at tycdigital dot com>
- Date: Wed, 28 Mar 2001 11:05:22 -0300
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
Hi!
I'm writing for the first time to this list with the hope that you can help
me.
1) I'm using RedHat 7 in an i386 platform
2) I've compiled last stable release of gcc (2.95.3; by the way, why RedHat
7 comes with an experimental
version of the compiler?!)
3) I've compiled glibc 2.2.2 with gcc 2.95.3
4) I've compiled binutils 2.10.1 with gcc 2.95.3 and linked it with glibc
2.2.2
5) I've not passed any --with-prefix to the configure scripts during 2),3)
and 4), so everything has been installed under /usr/local
I really don't want to replace RedHat 7 libc (I can't remember its version
now). The first thing I have done, after realizing that my new ldconfig uses
/usr/local/etc/ld.so.conf was editing that configuration file. Another thing
I discovered was that ldconfig was by default searching for libs in
/usr/local/lib instead of /lib and /usr/lib. Although undocumented (at
least, I couldn't find any doc on this) these behaviours seem pretty
coherent with my installation. My /usr/local/etc/ld.so.conf was looking like
this after editing it:
/usr/lib
/lib
Running ldconfig -v showed the following search order:
/usr/local/lib:
......
/usr/lib:
......
/lib:
.....
Obviously, gibc was founded twice, first in /usr/local/lib and the in /lib.
Then I changed the dynamic linker simbolic link to my new dynamic linker in
/usr/local/lib.
After all these steps ldd <any executable linked to a shared libc.so.6> (for
example ldd /usr/local/bin/gcc) should show that libc.so.6 soname was
resolving to (=>) my new glibc. But the fact was that it was still resolving
to my old RedHat 7 glibc. Then, the dynamic linker being the new one, my
programs crashed all the time.
After trying all sort of things, I discovered why it was working this way
reading the output of ldconfig -p (the /usr/local/bin ldconfig). The type of
shared library showed was different for both glibcs (the item between
'(',')'). The RedHat 7 one was a libc6 while the new one was loosely an ELF
(well, they still are). So every library in /usr/local/bin was being cached
first than it's twin in /lib (and obviously enough, the type of every one is
libc6), except glibc. I tried then upgrading my /usr/local/etc/ld.so.conf to
the following:
/usr/local/lib=libc6
/usr/lib
/lib
After running ldconfig and relinking /lib/ld-linux.so to my new dynamic
linker everything worked fine and was linking with the new glibc. So the
problem was in the type of the libraries. I'm not sure of the exact meaning
of this type but the thing to think seems to be that they show the
dependencies of a library (also I have found some advices about linking
explicitly against libc (-lc) in order to let ldconfig -p find the
dependencies of the lib being built). With this in mind, depending in itself
seems such a sick thing for a library to do. So why RedHat 7 libc do this or
why ldconfig behave like if this were true?
Although now my system is running as I wanted it to do, I would like to find
a clean solution or at least to be sure of which player is not fair playing.
By the way, why is the resolution order of ldconfig (I mean, the order in
which ldconfig writes the cache entries) so badly documented? Is this
intentionally ambiguous, are the current implementations very heterogenous
or is this simply bad documentation? For example, every man page I've read
says something like:
"""
ldconfig creates the necessary links and cache (for use by the run-time
linker, ld.so) to the most recent shared libraries found in the directories
specified on the command line, in the file /etc/ld.so.conf, and in the
trusted directories (/usr/lib and /lib).
"""
But which is the exact order of the search algorithm (ok, i know it as ad
hoc cases for both of my ldconfigs, but this is the kind of knowledge I
would like to avoid when possible)? Why is the version of ldconfig in
/usr/local/bin using /usr/local/lib instead of /lib and /usr/lib? Why and
how the type of shared library affects the order of
the cache entries?
Thank you in advance,
Carlos
Sorry if my English is not the best.