The old build wrapper, and why it was abandoned.

Rob Landley rob at landley.net
Sun Oct 26 06:50:17 UTC 2008


Originally, uClibc provided a build wrapper that let people use their existing 
compilers to link programs against uClibc, by rewriting the command line 
arguments before calling gcc, but this was abandoned for the following 
reason:

Long ago in the dark ages, gcc introduced libgcc.a as a place to store 
functions the compiler could magically insert calls to behind the scenes, 
such as the code to perform a 64 bit integer division on a 32 bit platform, 
and the stack unwinding code C++ forced C to bloat its longjmp() with.

Later, gcc 3 introduced a dynamic version of this library, libgcc_s.so, so it 
didn't have to statically link this code into each binary that used it.  And 
that's where it all went pear shaped.

The problem is that dynamic libraries can require other dynamic libraries, and 
libgcc_s.so requires libc.so.  This means that if your compiler was built 
against glibc, then libgcc_s.so will link against glibc, and anything that 
causes the compiler to suck in libgcc_s.so will leak a reference to glibc 
into your uClibc program.

There's no way to stop libgcc_s.so from leaking a reference to libc, all you 
can do is build a version of gcc against uClibc so that its libgcc_s.so is 
leaking a reference to the _right_ C library.  And hence the build wrapper 
was abandoned in favor of buildroot, a tool to build a new uClibc compiler 
from source code.

Now _my_ question is, why not just have the wrapper link against libgcc.a by 
default?  Go ahead and dynamically link the other libraries, but always 
statically link this one so it doesn't leak this problematic reference to 
glibc.  The compiler has to have a libgcc.a in order to support static 
linking at all.  Yes, the resulting binaries are slightly larger, but as a 
quick and dirty way to get a build environment it still works just fine.

Does anybody see a reason why the build wrapper should _not_ be added back to 
uClibc, with this change, so people don't have to create a separate toolchain 
just to try out uClibc?

Rob



More information about the uClibc mailing list