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

[Tom Cameron]

Hello,
	I would like to note that I don't like the idea of having
multiple libraries (libcrypt, libresolv, etc.).  I like having one
library that my programs link against.  This means that I don't have to
set a million-and-a-half options if my libs aren't in a standard place,
and that the end file system has less overhead (depending on what fs you
use, this could be many bytes to nearly a kilobyte.  That's my .25
(inflation).  Just something to think about before we create a little
gnu.  Cooking times may vary.  ; )

--
Thomas Cameron
Network Technician / Operations Specialist
St. Mary's Bank

> -----Original Message-----
> From:	Manuel Novoa III [SMTP:mnovoa3 at bellsouth.net]
> Sent:	Tuesday, April 17, 2001 8:19 AM
> To:	Michael Shmulevich
> Cc:	andersen at lineo.com; Tom Cameron; uclibc at uclibc.org
> Subject:	Re: [uClibc]cvs commit to uClibc/ld.so by andersen
> 
> 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