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

[Manuel Novoa III]

Erik,

On Mon, 16 Apr 2001, Erik Andersen wrote:
> Well, right now is is about 20k and doesn't work at all.  Easpecially not
> for things like ELF binaries...  I'm reading through some shared lib
> loader code to make sure I understand everything involved in making
> one that actually works.  So far I just took some code, make it compile,
> and checked it in.  But that code is (as Michael Shmulevich correctly
> noticed nad much to my embarassement) designed for a.out junk...
> 
> So the stuff that I checked in isn't going to work at all.  The ELF loading
> stuff in the ld.so package (in the d-link directory) is ugly and was designed 
> to work around the failings of a badly designed C library.  The stuff in Glibc 
> looks workable, but seems overly large.
> 
> For the moment I think I'll just remove the ld.so junk to avoid further 
> embarassment,

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).  The later also looks for the ld.so.cache file in
/usr/<arch>-linux-uclibc/etc and I've built the appropriate versions of
ldconfig, ldd, etc.  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.  I've successfully used this even with libdl.so.  I
was just waiting for your input about directory locations.  Oh yes, of course
you need to set DYNAMIC_LINKER appropriately when you build the gcc wrapper.

Manuel