[uClibc]cvs commit to uClibc/ld.so by andersen

Manuel Novoa III mnovoa3 at bellsouth.net
Tue Apr 17 12:18:37 UTC 2001


Michael,

On Tue, 17 Apr 2001, Michael Shmulevich wrote:
> Manuel Novoa III wrote:
> 
> > Maybe I wasn't clear in my emails earlier.  I have a patched version of
> > ld.so-1.9.11 which generates two dynamic linkers ld-linux-<arch>-uclibc.so.1;
> > one looks in /lib and /usr/lib as usual (intended for a glibc-less system) and
> > one which looks in /usr/<arch>-linux-uclibc/lib only (intended for a
> > development system).  
> 
> I don't see why this is so important. For the moment you may assume all 
> libraries at the target machine reside under /lib and /usr/lib, and 
> don't care for development. If you put some libraries in unusual place, 
> just add it to LD_LIBRARY_PATH, and create a softlink for 
> /lib/ld-linux.so to point to a correct place. If you crosscompile, then 
> you won't able to run the programs on development machine either, so I 
> don't care much for the place of shared libs and ld-linux.so.

Several points here:

1) LD_LIBRARY_PATH is ignored for suid bins.  To get around that, I even
modified  the gcc wrapper to use the -rpath linker option.  In fact, my working
version does that now when you want to test with the uninstalled shared lib in
the build directory.

2) Using a customized dynamic linker that looks for shared libs _only_ in a
directory of uClibc-compatible shared libs allows us to use the standard method
of adding libs to the gcc (wrapper) command line.  For instance, doing
something like -ldl with the new scheme, where libdl.so.1 exists in the uClibc
shared lib directory, links the correct library.   The only way I could get
this to happen without a customized dynamic linker was to explicitly list
/lib/libdl.so.1 on the command line.

3) As an extension to (2), we can now build libuClibc.so.1 as libc.so.1 without
conflict.  This wasn't so much a problem now, but as Erik wants to start
breaking things up into libcrypt, libresolv, etc.  this was going to become a
problem.  I didn't want to have to start using libuClibcrypt, libuClibresolv,
etc. or any other "non-standard" naming scheme.  Why force ourselves to make
the modifications to Makefiles that would be necessary when we can avoid that
by using standard names.

4) Obviously you won't be running cross-compiled programs on a develpment
machine.  But if you're developing and running on the same arch, using the
customized linker on the devel machine lets you avoid name-clashes with the
standard libs on your system.  And, since the two customized dynamic linkers
have the same name and live in the same place,
/lib/ld-linux-<arch>-uclibc.so.1, you don't have to relink things to move to the
target system.  All you need to do is put the version of the dynamic linker
that looks in the standard places for libs and ld.so.cache on the target and
you can put you uClibc-compat shared libs in /lib and /usr/lib, just as you
would with the glibc-compat libs on a normal system.  

> You seem to unnedingly complicate the matter. I use ld.so as-is, with 
> some minor assembly corrections, and it works.

Believe me, I would love it if you can show me how to add -ldl to the gcc
wrapper command line and have things build and run correctly.  I for one would
love to hear what these "minor assembly corrections" are.

> > The later also looks for the ld.so.cache file in
> > /usr/<arch>-linux-uclibc/etc 
> 
> This is particularly bad idea, since you cannot cross-create ld.so.cache 
> at all.

Thank you for thinking I'm such an idiot...

There are _2_ versions of the dynamic linker.  One (devel) consults
/usr/<arch>-linux-uclibc/etc/ld.so.cache, which is built by a customized
ldconfig.  The other (target) consults /etc/ld.so.cache as usual.  This avoids
problems when glibc-compat and uClibc-compat shared libs having the same names
and major numbers on the devel system.

> > The idea is that you put the second version in /lib on the
> > devel system, and it works (assuming same arch of course).  You put the first
> > version in /lib on the target system.  Since the paths of the shared libs
> > aren't included in the compiled bins, the shared lib dependencies are resolved
> > correctly in both cases.  
> 
> How does ld-linux.so know whether it runs on development system, or a 
> target machine?

Once again...  there are _two_ different versions with the same name.  The only
differences between the two are the paths they use to locate shared libs and
the path they use for ld.so.cache.

> > I've successfully used this even with libdl.so.  

As have I.  But only if I explicitly added /lib/libdl.so.1, not -ldl, to the
gcc wrapper command line.  Again, the only way I have found that gives the
correct behavior is using a customized dynamic linker.

In fact, here is a quote from a message I posted to this list, and emailed
directly to _you_, on April 12.

-------------
Now, if anyone has any suggestions as to how to get correct behavior from
the wrapper on a development system _without_ having a custom dynamic linker,
please let me know.  I've gone through the info pages for both gcc and ld with
no success.
--------------

As yet, I have received no replies.  The question still stands however.

Manuel





More information about the uClibc mailing list