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

Tue Apr 17 23:45:23 UTC 2001

I have to admit that I'm with you on this one...

And I do not see why having separate library ease the compilation too

Jean-Yves
---
Jean-Yves Avenard
Hewlett-Packard - Embedded and Personal Systems / Platform Technology Group
351 Burwood Hwy, Forest Hill, Victoria 3130 - Australia
Tel: +61 3 88773740 - Fax: +61 3 9802 7714 - mail: jean-yves_avenard at hp.com

> -----Original Message-----
> From: Tom Cameron [mailto:TCameron at stmarysbank.com]
> Sent: Wednesday, 18 April 2001 5:22 AM
> To: 'Manuel Novoa III'; Michael Shmulevich
> Cc: andersen at lineo.com; Tom Cameron; uclibc at uclibc.org
> Subject: RE: [uClibc]cvs commit to uClibc/ld.so by andersen
> 
> 
> 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
> 
> 
> _______________________________________________
> uclibc mailing list
> uclibc at uclibc.org
> http://uclibc.org/mailman/listinfo/uclibc
> 