[uClibc] Buildroot issues

[Erik Andersen]

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.

Problem: ld
	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.

	Possible solutions:
		*) Patch ld to control lib paths and rebuild.

Problem: libgcc
	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
	and structures.

	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.

	Possible solutions:
		*) 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

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