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

Tue Apr 17 16:47:22 UTC 2001

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

Adding -rpath means, on target libs must be in RPATH directory. I don't
know if it a wanted behaviour. I am quite safe with /lib. You may think
otherwise though. Even so, you may be right and I am wrong, since I am 
creating a customized system for my company's needs.

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

I assume you read 'ld' man page :-) So, if you did, you'd know that
linker doesn't know to search for libdl.so.1, but libdl.so. To make
compilation even more efficient, you may even add -L flag.

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

Agreed. Why don't we do so right now? I don't see any problem of making
all generated binaries to sit under lib/, and adding correct -L flag to
our gcc.

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

Maybe I am not getting your point. Anyway, why would I want to put 
/lib/ld-linux-mips-uclibc.so.1 on x86 development machine? If you're 
talking about  running x86-compiled binaries that were compiled on x86 
dependant on libuClibc.so.1, then again, I can do so even today. Without 
any need for DT_RPATH in dynamic  linker. Because there is only one 
libuClibc.so.1. In /lib.

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

As for libdl, on my ld.so source tree I get libdl.so file created under 
d-link/libdl. adding -L flag simply solved the problem. As for assembly, 
you seem not to need those, since on your computer it works as is. I may 
send them later on though.

 >> This is particularly bad idea, since you cannot cross-create
 >> ld.so.cache  at all.
 > Thank you for thinking I'm such an idiot...

Please, no hard feelings. I remember that you do not do so many 
cross-compilations, and just pointed the problem out to you.

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

Still, the problem is: how I can create ld.so.cache for MIPS on x86?

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

Manuel, this may sound stupid for myslef, but how can there be two files 
with the same name? And for two different architectures?

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

The answer is: I don't know. I use custom dynamic linker ld-linux.so.1 
for all platforms, silently ignoring whatever kernel wants me to use. I 
assume since .interp section contains a route to a valid dynamic linker, 
I don't care to much for a compilant name. 'ld' does pretty fine job of 
searching for dependencies, and it works no matter what dynamic linker 
do you intend to use for the binary.If you want to use *your* libc.so, 
libm.so, libresolv.so, just tell thelinker where to look for them. By 
default values are taken from *real* gcc's spec file, but you may 
override the searched directories with -nostdinc and -nostlib. After 
this, use -L to tell where you want ld to find the libraries.

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

Do you need an answer now, after all?

Thank you for your comments.

Sincerely yours,
Michael Shmulevich
______________________________________
Software Developer
Jungo - R&D
email: michaels at jungo.com
web: http://www.jungo.com
Phone: 1-877-514-0537(USA)  +972-9-8859365(Worldwide) ext. 233
Fax:   1-877-514-0538(USA)  +972-9-8859366(Worldwide)