[uClibc] uClibc-0.9.24: ldd/ldconfig build errors

Charlie Brady charlieb-uclibc at e-smith.com
Wed Dec 24 23:42:04 UTC 2003


Thanks for the reply, Carl. Useful stuff.

On Wed, 24 Dec 2003, Carl Miller wrote:

> > > I think this can be fixed by a custom spec file for gcc. We'll see.
> > 
> > Not even that. See below.
> 
> Anything that can be solved by giving the right command-line options to
> gcc can be solved by a custom specs file.

As I'm discovering. Makes me wonder why the compiler wrapper was done the 
way it was, rather than via a specs file. The conditional manipulation of 
gcc arguments (formerly) done by gcc-uClibc seems to map quite well onto 
specs file capabilities.

> It's just the matter of finding
> the right set of command-line options to specify either on the command
> line or in the specs file.

Are you aware of any uClibc compile and link problems which can't be 
specified via command line options?

> In addition to those options, try adding:
> 
>     -Wl,--dynamic-linker,{PATH-TO-YOUR-INSTALLED}ld-uClibc.so.0
>     -Wl,-rpath,`pwd`/../lib,-rpath-link,`pwd`/../lib

Well, that links OK, but doesn't run very well:

[charlieb at localhost utils]$ LD_LIBRARY_PATH=../lib ./ldd ldd 
Segmentation fault 
[charlieb at localhost utils]$

OTOH, the stock binutils ldd (glibc) runs fine:

[charlieb at localhost utils]$ ldd ldd
(overflow)      libc.so.0 => 
/home/charlieb/rpms/BUILD/uClibc-0.9.24/utils/../lib/libc.so.0 
(0xf7096000)
(overflow)      ld-uClibc.so.0 => 
/usr/i386-linux-uclibc/lib/ld-uClibc.so.0 (0x167000)
[charlieb at localhost utils]

I guess if ldd doesn't segfault I don't really need the uClibc version. 
But I've clearly got a uClibc dynamic loader problem.

> There's probably a better way to come up with the absolute path to your
> installed uClibc library directory.  Feel free to substitute that.  And
> note that ld-uClibc.so.0 above must also be given with a full pathname.

Understood. 

> > [charlieb at localhost utils]$ LD_LIBRARY_PATH=../lib ./ldd ldd
> >         libtermcap.so.2 => /lib/libtermcap.so.2 (0x00ebf000)
> >         libdl.so.2 => /lib/libdl.so.2 (0x00b23000)
> >         libc.so.6 => /lib/tls/libc.so.6 (0x003b3000)
> >         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0079d000)
> > [charlieb at localhost utils]$
> 
> Your ldd was compiled to use the system-native ld.so and the system-native
> dynamic library search path.  Both should be changed to the uClibc versions.

Why should the uClibc versions be used? In the more general case that I'm 
building cross-development tools, uClibc may not even be installed on the 
build host.

> I think the options I gave above should do that.

See above.

> In general, when debugging stuff like this, it's helpful to try running all
> your compiles with "gcc -v".  That will show you in gory detail exactly how
> each component of the compiler is being invoked.  In particular, you'll see
> all of the options provided by the specs file, which, in this case, would
> have included specifying the system-native ld.so and dynamic library search
> path.

Yes, I did use -v when investigating the link problem. I just left them 
out where quoted above for briefness.

I can see what Erik means about ld's stubbornness in searching "standard 
locations":

...
 /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/collect2 --eh-frame-hdr -m 
elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o ldd -L../lib 
-L/usr/lib/gcc-lib/i386-redhat-linux/3.3.2 
-L/usr/lib/gcc-lib/i386-redhat-linux/3.3.2/../../.. -s /tmp/ccMA7xvF.o 
/usr/i386-linux-uclibc/usr/lib/crt0.o -lc -verbose -nostdlib
...
ENTRY(_start)
SEARCH_DIR("/usr/i386-redhat-linux/lib"); SEARCH_DIR("/usr/lib"); 
SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib");
...

When you've got the flexibility of a macro languages such as the specs 
file, why hard code stuff in? Seems there is no way to avoid searching 
the "standard places" - which seems like a bug to me. Certainly doesn't 
match documented behaviour of "-nostdlib":

   -nostdlib
      Only search library directories explicitly specified on the command
      line.   Library  directories specified in linker scripts (including
      linker scripts specified on the command line) are ignored.


--
Charlie




More information about the uClibc mailing list