toolchain - a newbie question

Rob Landley rob at landley.net
Sat Dec 2 16:45:34 UTC 2006


On Tuesday 21 November 2006 11:16 am, Khem Raj wrote:
> 
> stari pas said the following on 11/21/2006 1:43 AM:
> > Hi,
> >
> > I've built uClibc libraries using gnu cross development tools.
> >   
> from where did you get this cross toolchain and how was it configured. 
> If this is configured for uclibc then you have pretty much everything.

Random question:

Other than gcc's paths being completely horked, and libgcc_s leaking a 
reference to the libc it was built against, what else in gcc needs rebuilding 
for a different libc?

The gcc path code is just plain evil (I could rant about this for 20 minutes 
if you're curious), so I'm resurrecting the wrapper script even though I'm 
rebuilding gcc from source.  I want a relocatable toolchain (a tarball you 
can extract into your home directory, add to the $PATH, and it just works), 
and gcc goes out of its way to screw this up.  I fought with removing gcc's 
multiple layers of conflicting brain-damaged path logic, and replacing the 
whole mess with something that actually works, but after my patch passed 
10,000 lines (mostly stuff I'd removed) I gave up because I don't want to 
maintain that against future gcc releases.  (Getting it merged isn't even an 
option; I've seen gcc patches languish out of tree for over 3 years even when 
the submitters jumped through all the hoops, just because they weren't a 
regular part of the gcc core team.  On top of that, I'm not signing my 
copyrights over to the FSF, and my license is GPLv2 only without the "or 
later".)

So I'm ressurrecting the old wrapper script to deal with this, because it does 
exactly what I want: run gcc with -nostdlib and -nostdinc and explicitly tell 
it on the command line where everything lives.

So my question is: I know the wrapper script was abandoned because you have to 
rebuild gcc from source to get a working version of libgcc_s anyway, but I 
need the wrapper script for different reasons.  So what _else_ needs to be 
rebuilt from source to switch between libc versions?  (I'm wondering if I 
could hack up some kind of "make libraries" target to populate a gcclib 
directory I can point the wrapper at.)

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery



More information about the uClibc mailing list