[uClibc] Buildroot issues
andersen at codepoet.org
Sat Nov 1 03:03:29 UTC 2003
On Fri Oct 31, 2003 at 07:26:10PM -0700, Manuel Novoa III wrote:
> Hello Tom,
> On Fri, Oct 31, 2003 at 05:18:05PM -0500, tom at ceisystems.com wrote:
> > Hello all,
> > The source of my issues is most likely to do with the gcc-3.3.mk
> > file. If you look back through CVS, you will notice that the gcc-*
> > files have changed a bit. (quite a bit) There used to be a file named
> > gcc_target.mk, which took care of building the compiler for the target
> > system. This is, of course, assuming you _wanted_ to make a compiler
> > for the target. I do not. Enter my issue.
> > If I tell buildroot that I _specifically_ do not want to build a
> > compiler, it will attempt to anyway. Good times. Of course, instead of
> > trying to build a compiler, it should just whip out a wrapper. Another
> > issue is that when it attempts to assemble the compiler, it looks for
> > the binutils in the build directory. Again, it should NOT be there, as
> > I am NOT supposed to be building a compiler, etc.
> > So, those are some things I have noted in the past few days.
> > Hope this helps track things down.
> Bad news for you. The gcc wrapper is being deprecated.
Just to provide some additional context...
The gcc wrapper toolchain relies on our ability to entirely
subvert an existing gcc/glibc toolchain and force it to create
uClibc binaries. The wrapper toolchain does a fair job at this,
but as uClibc has improved, it has allowed us to realized there
are fundamental problems with the wrapper toolchain that we
simply cannot fix. It turns out that our basic underlying
assumption, that we can entirely subvert an existing gcc/glibc
toolchain, is flawed.
The linker (ld) will go looking for libraries all over
the host system, just as it was compiled to do. If
libfoo is missing but is present on your development
system, ld will try to use the library for your host.
*) Patch ld to control lib paths and rebuild.
When gcc is built, for whatever perverse and twisted
reason, libgcc is linked against glibc. The wrapper is
generally able to produce working binaries when using the
static libgcc.a, and when your application code only
needs functions that are not also using glibc symbols
But increasingly, gcc is being built and released using
a shared libgcc. This is a _good_ thing for many
embedded systems, but you cannot use a shared libgcc
that was compiled vs glibc with uClibc binaries.
*) Build libgcc (along with gcc) linked vs uClibc.
*) Patch up libgcc to remove all libc functions.
*) Force apps to always use bits from the static
glibc linked libgcc and then hope your app is
only using the libc agnostic bits.
You will notice that in each case, the only way to fix these
problems is to rebuild your toolchain. Which is why we have
decided that the wrapper toolchain must be depricated and
we will shortly be posting a big fat warning about its use.
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
More information about the uClibc