Fw: Re: Word of Emdebian at LinuxWorld Exp (London) ?
Erik suggested using uClibc by default for emdebian. I thought that sounded
very sensible. Here's the conversation so far.
----- Forwarded message from Erik Andersen <andersen@codepoet.org> -----
From: Erik Andersen <andersen@codepoet.org>
Date: Tue, 28 Oct 2003 18:39:06 -0700
To: Wookey <wookey@aleph1.co.uk>
Subject: Re: Word of Emdebian at LinuxWorld Exp (London) ?
Reply-To: andersen@codepoet.org
User-Agent: Mutt/1.5.4i
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....
uClibc is also less tested than glibc. We test the heck out of
it, but there may be obscure corner cases that we have somehow
missed. But I do have fully working Debian/uClibc system for x86
I've assembled and everything including dpkg, apt-get, perl, gcc,
make, etc is working nicely.... So I must be doing at least
something right. :-)
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.
> But yes - that actually seems like a very sensible way to get very good
> compatibilty and significant size savings.
>
> I admit I haven't played with uclibc much, although I had an argument with
> it last week trying to compile geexbox and got into a tangle with locales
> not working (it failed with gen_locale claiming that 'iso8859-1 was not
> supported' IIRC which seemed unlikely to be true). I see that you scripts
> are full of caveats about them all being vile, until someone makes something
> nicer :-).
Yeah. mjn3 is funded to finish scrubbing the locale generation
tools up during November and December... Until that is finished,
the recommended route is to either use the pregenerated set of
locale data, or leave locale disabled. I built Debian woody vs
uClibc with locale support entirely disabled.... After compiling
up libintl and gettext, everything works as expected.
> BTW did you intend this to be a private email, or should I copy it to the
> list?
Feel free to share... I've got no secrets. :-)
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
----- End forwarded message -----
--
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: