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 <[EMAIL PROTECTED]> ----- From: Erik Andersen <[EMAIL PROTECTED]> Date: Tue, 28 Oct 2003 18:39:06 -0700 To: Wookey <[EMAIL PROTECTED]> Subject: Re: Word of Emdebian at LinuxWorld Exp (London) ? Reply-To: [EMAIL PROTECTED] 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/
