[uClibc]DYNAMIC_LINKER for gcc

Manuel Novoa III mnovoa3 at bellsouth.net
Thu Apr 12 15:46:43 UTC 2001


Michael, (Erik please read)

On Thu, 12 Apr 2001, Michael Shmulevich wrote:
> Hello,
> 
> I have found a serious problem with gcc's wrapper: it adds 
> DYNAMIC_LINKER to the list of linked objects, and the 
> -Wl,--dynamic-linker flag is incorrect.

I found and fixed this on Saturday.  A commit message and a "chatty" message
were posted to the mailing list then.  I guess you missed them.  Originally, I
had messed up the dynamic-linker flag and later Erik had added the dynamic
linker to the arg list... fixing a symptom but not the problem.

What time I've had to work on uClibc (not much lately) has been devoted to
straightening out some issues with the wrapper.  My current version is somewhat
different from that in the CVS.  I need to talk some things over with Erik
before I commit it.  

New features:

1) Wrapper deals with issues like using the libs from the build directory vs.
the install directory.

2) Wrapper uses a uClibc-customized dynamic linker if you have one.  This
avoids problems with name clashes on shared libs.  See below.

3) Wrapper makes use of -rpath in some cases (optional) so that the
uClibc-based executables know where to find there shared libs without having to
install them, run ldconfig, or set environment variables.

> Summary: if you want to add specific ld.so for libuClibc.so add it to 
> NEEDED list of libuClibc.so, not the executable. This way we are keeping 
> things consistent.

There is a more general problem.  Erik wants to break things up into shared
libs along the lines of glibc, i.e. libm, libresolv, etc.  Users will also want
to be able to build uClibc-specific shared libs.

The only way I've been able to avoid name-clashes with the glib libs in /lib is
to hack a uClibc-specific dynamic loader based on ld.so-1.9.11 that only looks
in /usr/i386-linux-uClibc1/lib for libs and uses its own ld.so.cache in
/usr/i386-linux-uClibc1/etc.  The directory names aren't "official"... I'd like
to get more feedback from Erik.  Ideally, the <arch> in the paths should be
generalized.

The above lets me pass -lc, -ldl, etc. on the wrapper command line and get the
correct behavior.  (In my case I'm using libc.so.1 as the shared name and
soname instead of libuClibc.so.1.  That seems resonable, since when we start
breaking things up, I don't think we want libuClibm.so, libuClibresolv.so,
etc.)  Of course, ld.so-1.9.11 only supports i386, m68k, and sparc. :-( 

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.  I think we could avoid it it we could turn off the use of
ls.so.cache for the uClibc-based executables, but I can't find a way to do that
without deleting /etc/ld.so.cache period.

To be honest, I'm just about at the point of thinking... "All I've got are
386-based systems.  I've got something that works for me. Anyone who
needs this fixed on another arch can port the dynamic linker or find another
solution.  There are other things I want to look at."  So, anyone with any
helpful suggestions, please give a shout.

> Also, I added -M flag check, which is used for dependency creation. The 
> issue was mentioned once in the list.

I'll add the -M flag for you (I apparently missed the original mention) but,
as I mentioned above, I probably won't be commiting a new version until I get
some feedback from Erik about the other issues.

Manuel





More information about the uClibc mailing list