[uClibc]Putting uclibc in a linux distribution?

[Rob Landley]

On Thursday 12 September 2002 10:14 am, Jeremy Jones wrote:
> Hey,
>
> Take a look at http://hints.linuxfromscratch.org/hints/uclibc-lfs.txt

Ooh, that one's new.  Seriously cool link, thanks.  (My hints directory is 
now four months out of date, time to refresh...)

Were any of the various problems it mentions (modutils not working, whatever 
a "faulty is* (ctype)" is) fixed in 0.9.15?    I vaguely remember somebody 
mentioning that perl now passes the full test suite, but I could be 
hallucinating with this cold.  (Last night I had laringytis.  When did the 
mostly indoor cat decide to go missing for four hours?  Of course...)  And 
did the rewrite of initfini.pl in awk happen yet...  (checking my tarball...) 
 Doesn't look like it...  hmmm...

If nothing else, this is a heck of a test case of uclibc development.  Thanks 
again...

> I'm now working on a the same thing, replacing much of the base packages
> with busybox/tinylogin.
>
> Rob, if you'd like to take my (derivitave and highly unoriginal) distro
> as an example, I can make it available for you.  All the patches,
> special ./configure flags, etc. are included in the build scripts.

As I said, my plate's full for a couple more weeks (and I have a cold that 
won't go away), but I am interested, yes.  Do you have plans to publicly 
release it?

One of my big goals here is a distribution that's as easily hackable as 
possible.  Distros that aren't easily buildable from source, by definition, 
don't cut it here.  (The entire concept of the "source RPM" is just wrong.)  
And ones that try to download the source  from the net during the build are 
impolite (sure, let's bog the mirrors, that's going to scale), brittle 
(websites go away: you can only rebuild the old version as long as the sites 
haven't changed), and don't buy you anything (if there's a new version of the 
package, how do you know it isn't buggy, or that the build commands didn't 
change?)

Smaller is more hackable.  (The FSF managed to take 823 lines to write 
"cat.c".  That's just wrong...)  There's less to learn, less code is easier 
to understand.  In the back of my mind I'm also thinking of using this as a 
teaching tool if I start doing the whole adjunct faculty thing again.  And my 
co-workers have to learn it to use it, which is a big bottleneck as well.  
Explaining to anybody how glibc really works...  No.  Just...  No.

On a side note, even though I'm not doing a stripped down embedded system I'm 
stealing a lot of their tricks.  One is that -Os actually performs better 
than a lot of the other optimization types for an obvious reason: more code 
fits in the L1 and L2 caches.  On a system where the CPU core has three 
execution units that are each clock multiplied at eighteen times the system 
bus speed, the memory bus is the main bottleneck, so smaller code runs 
faster.  These days, things like loop unrolling can actually be 
counterproductive.  I still can't figure out why this comes as a surprise to 
so many people...

> Jeremy

Rob