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

Erik Andersen andersen at codepoet.org
Mon Sep 1 18:24:42 UTC 2003


On Wed Aug 20, 2003 at 03:13:04AM -0400, Rob Landley wrote:
> 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?)

We get some entries twice because, as a wrapper, we have to take
some rather absurd precautions based on incomplete information,
because of the mind-numbingly complex set of gcc and binutils
options.  We try and preempt to problems before they get a change
to screw things up (in this case related to people manually
setting the rpath).

> 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...

The FSF _never_ maintains man pages.  Rememer that "info" is the
official form of GNU documentation.  One of these days perhaps
they will see the wisdom of more advanced things like docbook.
But I'm not holding my breath.

Anyway, try 

    gcc -nostdinc -isystem /usr/include hello.c -o hello -v

and it won't work since you just get
    /usr/include
as the include path.

and then try:

    gcc -nostdinc -isystem /usr/include -iwithprefix include
    hello.c -o hello -v
    
which does work, since you get the gcc include files as well 
as the system ones, i.e.:

    /usr/include
    /usr/lib/gcc-lib/i386-linux/3.3.1/include

> 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?)

crt0 provides the __start entry point for apps not needing
to use ctors/dtors (constructors and destructors).

crt1 provided the __start entry point for apps that are
using or could be using ctors/dtors.

All the crtbegin, crti, crtend, and crtn stuff is all needed for
handling constructors and destructors properly.  Specifically,
crtbegin and crtend are provided by gcc, while crti and crtn are
provided by uClibc.  The complete set of crt1, crtbegin, crti,
crtend, and crtn is all needed just to make ctors/dtors work.
It's a nasty business making ctors/dtors work as expected...

If you do not need ctors/dtors, you can disable UCLIBC_CTOR_DTOR,
all that garbage will be skipped, and life will be simple and
elegant.

> 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?)

uClibc does not replicate libgcc, and libgcc does not depend on
any C library at all.  So we use the math and builtin functions 
provided by gcc when possible, since we don't want to implement
things like arch specific division and whatnot.

> 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?

The crtbegin, crti, crtend, and crtn stuff is all needed for
handling constructors and destructors properly.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--



More information about the uClibc mailing list