[uClibc] uclibc++

Rob Landley rob at landley.net
Mon Aug 30 21:32:30 UTC 2004

On Monday 30 August 2004 09:42, Rogelio M.Serrano Jr. wrote:

> > A) Who said I was targeting embedded?
> >
> > B) They say how to build stuff.  I rip out half their packages in the
> > systems
> > I build.  (libtool?  *shudder*.)
> >
> >> -mike
> >
> > Rob
> It all works with buildroot. LFS is optimised for glibc.

Actually it isn't optimized for anything, it's just a set of instructions.  
It's a distrobution compiling HOWTO as much as anything else, between the 
various "hints" files and BLFS there's a whole lot of options and that's 
without actually understanding what you're doing and making your own 
configurations up (which is the whole point of the exercise).

> Buildroot is a better way to build a uclibc based system.

Buildroot has never had a stable release, just a series of random CVS 
snapshots that may or may not work today, and depends on downloading 
snapshots of code from servers out on the net that remove the versions it's 
using on a semi-regular basis (because there are so many).  It's constructed 
as a series of nested make invocations (I _hate_ mixing declarative and 
imperative sections in the same language) that make it a bit of a pain to 
figure out what it's doing in places.  It once ate chunks of my host system 
because I was stupid enough to do "make uninstall" on it.

Last I checked, you couldn't run buildroot from the environment created by 
buildroot; I.E. it doesn't rebuild under itself.  (Somebody was working on 
it, though...)  My system _does_ rebuild under itself, that was one of my 
primary goals for the thing.

There really isn't a whole lot of documentation on the thing (in fact I'm the 
one who pestered Eric into starting "README.patches").  You have to read the 
list to learn to unset CC, or that OPTIMIZE_FOR_CPU=i686 didn't work for the 
first year I knew about it (maybe it's been fixed recently), or how to select 
whether the target system should have build tools in it or not.  (I see that 
the toolchain build script has new been split up into a seperate binutils and 
gcc .mk files, which probably makes things easier to read through.)

I'm not attacking it.  I'm glad it's there, and I study what buildroot is 
doing all the time to try to figure out how it gets some package or other to 
work under uclibc.  But it's not the basis for what I'm doing.

And it shouldn't HAVE to be.  Is there "one true way" to build a glibc system?  
(And if you don't use that cannonical build process there's something wrong 
with you?)  Is uclibc supposed to be a flexible component you can drop in as 
part of a working Linux system, or a toy that only works in one specific 

www.linucon.org: Linux Expo and Science Fiction Convention
October 8-10, 2004 in Austin Texas.  (I'm the con chair.)

More information about the uClibc mailing list