snapgear ucfront and uclibc 0.9.28.2 warnings

[Rob Landley]

On Wednesday 14 March 2007 8:12 pm, David McCullough wrote:
> I would have to say that ucfront has proven to be anything but a hack.
> When you want to use a compiler,  but you don't care for it's libc/it's
> kernel headers or anything else it has included,  a wrapper allows you
> to do the --nostdlib/--nostdinc thing and use your own.

I've been meaning to look at the ucfront wrapper, but it's buried a bit down 
on my todo list.  The one I've been using is working fine for me (although I 
need to test more packages and C++ support in my version is only theoretical 
and totally untested at the moment).

The wrapper I'm using was actually maintained by Chris Faylor for timesys for 
something like 3 years before I got ahold of it, so it's already been greatly 
extended and made to work with gclibc and was a hideously ugly piece of...  
Ahem, I did a lot of cleanup.

> I think the purpose of the wrapper in this case is quite different to
> what the uClibc wrapper did,  and if not,  then fine,  it is working for
> our context on many arch's unmodified,  obviously it didn't work in the
> uClibc context.

The fundamental problem is you either need a compiler built 
with --disable-shared or a version of libgcc_s.so built against uClibc for 
the appropriate target.  The only way to get _either_ is to build gcc from 
source, so there's no getting away from that.  A wrapper doesn't help you 
there.

Some people think that if you build gcc from source you can patch its' 
internal path logic and thus don't need a wrapper, which generally means 
they've either A) never tried it, B) never tried to do anything fancy, C) 
been very lucky.  The path logic in gcc is a _crawling_horror_.  Run the 
sucker under strace sometime if you don't believe me.

Rob
-- 
Vista: Windows Millenium Second Edition