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

Rob Landley rob at landley.net
Thu Sep 4 02:43:32 UTC 2003


On Monday 01 September 2003 14:24, Erik Andersen wrote:
> 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).

Just making sure the duplicates aren't necessary.  (Particularly the "-lgcc 
-lc -lgcc" trio, I've bumped into stuff like that before where it DID 
matter...)

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

That's fairly evil.  (Then again, I seem to have to parse out the gcc install 
path in order to explicitly link in some of their object files and libraries, 
so...)

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

I know what consructors and destructors are in theory, but outside of c++ how 
the heck do you tell if your code is using them?  (What, something calls 
atexit?  Something to do with dynamic linking of libraries, or weak symbols?  
What?)

Does crt1 work for code that doesn't use constructors?  (Is it just a little 
bigger, or will it fail?)

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

I understand that it's tough making them work, I'm just wondering under what 
circumstances making them work is necessary (in straight c code, which is all 
I'm trying to compile at the moment.)  I take it hello.c can largely ignore 
this, but it might bite in xfree86 or openssh?

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

How do I know if I need them?  (I understand the answer to that question is 
almost certainly "if you have to ask, you don't", but I'm asking anyway...)

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

Which only need to be included once?

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

Okay.  Cool

>  -Erik

Rob





More information about the uClibc mailing list