snapgear ucfront and uclibc 0.9.28.2 warnings

[Rob Landley]

On Tuesday 13 March 2007 11:35 pm, Mike Frysinger wrote:
> > Here is a patch. (Against snapgear 3.3.0's ucfront.)
> 
> ok ?  we dont maintain that stuff at all (snapgear does!)
> 
> in fact, the wrapper was killed off because it is such a horrible hack ... 
sad 
> to see the uClinux-dist guys going down that dead end path yet again

Actually, I've revived the wrapper and I'm using it in Firmware Linux.  Go to 
http://landley.net/hg/firmware click on "manifest" up at the top, and drill 
down to "sources/toys/gcc-uClibc.c".

I'm using it to bypass all the broken path logic in gcc.  When I make a cross 
compiler, I want to tar it up and extract it in an arbitrary directory, and 
after spending a couple weeks ripping out _five_layers_ of broken path logic 
overriding each other and winding up with a patch deleting more than 10,000 
lines before I was even halfway through (See 
http://landley.net/notes-2006.html#15-11-2006 also the Nov 3, October 18, 
Octoboer 16, October 15, October 10...) I went "screw it, wrap the sucker, 
feed it --nostdinc and --nostdlib, and explicitly tell it where everything 
is".  Which is what the old wrapper did, although it needed some working to 
bring it up to date.  (

The old "unfixable" proboblem uClibc had was that libgcc_s.so leaks references 
to the libc it was built against, so you have to rebuild gcc from source 
against uClibc, to get it to leak references to the _right_ C library.  I'm 
doing that anyway (I both build my cross compiler against uClibc and 
configure it with --disable-shared so there's no libgcc_s.so to leak 
anything), but I still need the wrapper to get something cleanly relocatable 
that I trust.  (Linux From Scratch has a big section on patching the 
toolchain to get the paths to do something sane.  I gave up on gcc's path 
logic: --nostdlib and --nostdinc and calculate 'em yourself.  Only way to go, 
and then you don't need to modify the underlying compiler's source at all.)

Yes, some people are big fans of gcc's most recent attempt to override its own 
internal path logic (sysroot).  Every time the gcc developers give up on the 
previous layer as "unfixable" they always write yet another one and LEAVE THE 
OLD ONE STILL THERE.  This is the fifth.  You can set paths via environment 
variables, you can set paths via ./configure, there are some hardwired into 
the source code, and it finds the location of argv[0] and constructs relative 
paths based on that, and NONE of it works properly.  (I tried to make this 
work.  It all accumulates into a gigantic hairball, and if you trust their 
fifth attempt more than their first four be my guest.  I'll be off in my 
corner using/maintaining the wrapper.  Wake me when they make their sixth 
attempt.

I find the wrapper a fairly straightforward workaround to the problem of not 
trusting gcc to find its own ass with both hands and a map.

> -mike

Rob
-- 
Vista: Windows Millenium Second Edition