[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