[uClibc] Understanding what the build wrapper does...

[Rob Landley]

So I'm trying to build a system that uses uclibc native, and has binutils and 
gcc that know to run and link against uclibc.  (Buildroot can give me a 
busybox that works against uclibc, but building the development tools within 
that buildroot doesn't seem to work for me, and it would be nice to know how 
it actually works anyway.)

The uclibc-gcc wrapper gets a bit confused when you do a chroot that makes the 
system gcc no longer accessable (I know you were compiled with this gcc over 
here, but I want you to use THIS gcc...)

So I temporarily replaced by system gcc with a script that just does echo $*, 
and ran the wrapper on "blah.c".  This was the result (with newlines inserted 
for sanity's sake):

----- snip -----
-nostdlib
-Wl,--dynamic-linker,/home/lfs/newfirmware/image/static/usr/i386-linux-uclibc/lib/ld-uClibc.so.0
-Wl,-rpath-link,/home/lfs/newfirmware/image/static/usr/i386-linux-uclibc/lib
-L/home/lfs/newfirmware/image/static/usr/i386-linux-uclibc/lib
-L/home/lfs/newfirmware/image/static/usr/i386-linux-uclibc/lib
-nostdinc
-isystem /home/lfs/newfirmware/image/static/usr/i386-linux-uclibc/include/
-iwithprefix include
/home/lfs/newfirmware/image/static/usr/i386-linux-uclibc/lib/crti.o
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/crtbegin.o
/home/lfs/newfirmware/image/static/usr/i386-linux-uclibc/lib/crt1.o
blah.c
-lgcc
-lc
-lgcc
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/crtend.o
/home/lfs/newfirmware/image/static/usr/i386-linux-uclibc/lib/crtn.o
----- snip -----

"man gcc" and "man ld" are almost helpful (you're sure the FSF is still 
maintaining them?).

I understand nostdlib, which says only use the libraries listed here.

-Wl passes an argument through to the linker, and we're specifying where the 
library loader and the runtime link path are.  (This is odd, because 
presumably this means that the resulting binary would try to run against the 
cross-compile tools directory, rather than a copy of uclibc installed on the 
target system under /lib.  So even if I could get the compiler to like the 
chroot environment, the resulting binary wouldn't...)

Next two lines: Why is -L /blah/lib listed twice?  (Is one of them supposed to 
be /blah/usr/lib, perhaps?  Or does listing it twice cause it to resolve 
symbols that point elsewhere in the same library or fun magic like that?)

-nostdinc says not to use the standard include path for system header files, 
and -isystem provides a replacement path.  Ok.

As for -iwithprefix...  Huh?  -iprefix was never specified (the man page sucks 
here, I am reassured that the FSF is still maintaining it.  What is the 
default value?), and the -isystem ended with "include", so what exactly are 
we trying to accomplish here?  I'm confused...

So moving on, we get to crti, crtbegin, and crt1.  What happened to crt0?  (It 
got built.  I saw it.  What do all these thingies do?)

So then the blah.c file shows up, and -lgcc, -lc, and -gcc again.  I take it 
this means that libgcc uses stuff out of the c library, and the uclibc 
implementation of that stuff potentially uses more stuff out of libgcc?  
(Does THAT stuff potentially use stuff out of uclibc?)

At the end of all that, we have more random object files; crtend (from gcc) 
and crtn (from uclibc).

Interestingly, the ld man page suggests that 

     ld -o <output> /lib/crt0.o hello.o -lc

Is sufficient for making "hello world" work.  I take it this is a bit 
outdated?

When I'm mangling binutils and gcc, the bits to change to get gcc support are 
that ld's default dynamic linker and library search path need to be right for 
uClibc, and gcc's stdlib and stdinc path need to be right for uClibc.  Beyond 
that, the compiler's default behavior be acceptable?  (I.E. is all that crti 
crt1 crtn suff really necessary, or does crt0 cover it?  Or are the three 
libraries pandering to gcc in some way?)

Rob