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

[Michael Shmulevich]

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.

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


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

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

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

I will give a try for bash compilation. Ultimately, all things should work now. 

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)