[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: uClibc (was: Emdebian at Linuxworld Exp..)



+++ Erik Andersen [03-10-28 18:39 -0700]:
> On Tue Oct 28, 2003 at 04:18:58PM +0000, Wookey wrote:
> > +++ Erik Andersen [03-10-27 17:27 -0700]:
> > > On Mon Oct 27, 2003 at 12:29:11PM +0000, Wookey wrote:
> > > > We wanted to set up something that kept us in step with Debian and it's
> > > > package maintainance, whilst having small packages - anything that involves
> > > > re-packaging or maintaining separate rule sets is just going to get bit-rot
> > > > and go out of sync.
> > > 
> > > Any interest in standardizing on uClibc for debian embedded?  I
> > > have built (but not yet released) an x86 cut of Debian woody
> > > (with a few bits from testing when using that was the simplest
> > > route to making the app work with gcc 3.3.2 which I was using).
> > > It works nicely,
> > 
> > Thart seems like a good idea. What are the cons? (i.e. presumably there are
> > a few things that might not work quite right?).
> 
> The only real cons are that we do not yet support all
> architectures that are supported by glibc.  But we do fully
> support most architectures that are used when doing embedded
> stuff -- x86, arm, mips, powerpc, etc....

OK - which isn't a con at all from the emdebian point of view as we're only
intending to support them anyway.

> uClibc is _much_ more configurable than glibc.  It fully supports
> mmu-less architectures, such as coldfire, arm7tdmi, etc.  uClibc
> support for soft-float is _much_ better than glibc.  For example,
> I would suggest that the Debian embedded should be entirely
> soft-float for arches such as arm, since that is significantly
> faster than using kernel fpu emulation.

That is a more sensible default I agree. Makes life difficult for the
ARM7500FE people, but it does seem more sensible than making it difficult
for everybody else, which is the current state of affairs. If we compile
everything for soft-float on arm how hard is it to use the real FPU on the
few chips (one chip?) that do support it - does everything need recompiling
due to incompatible ABIs?

Even in this case I think it's still worth doing, as FPUed arm chips are in
such a tiny minority, but Vince might complain (as an arm7500FE machine vendor :-).

> I built Debian woody vs
> uClibc with locale support entirely disabled....  After compiling
> up libintl and gettext, everything works as expected.

Did you use pbuilder or something for this? Sounds like emdebian should steal
your config/set-up for this, as it's presumably pretty-well what's required
for our scheme, modulo the new emdebian targets. 
Is it in an accessible form somewhere we can take a look at?

Wookey
-- 
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK  Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/     play: http://www.chaos.org.uk/~wookey/



Reply to: