Le 27/05/2015 17:51, Irrwahn a écrit :
> No intention to lessen your main point, but that last observation
> does not come as a surprise. Development systems inherently have
> an installation overhead compared to simple runtime environments,
> it's always been that way. However, it amazes me what heaps of
> packages one has to wade through to get a minimal usable GNU/Linux
> system/capable of replicating itself/. (I'm currently digging my
> way through Linux from scratch, as an educational exercise.)

     Hey Urban. I tried this path one or two years ago but it works only 
for one version of each package, and they were all pretty outdated, 
particularly the uClibc version. Therefore, I found it an interesting 
exercise, but I wouldn't expect it to produce a cutting edge 
environment. I tried with more up to date packages and wasted my time.

Le 27/05/2015 19:19, Laurent Bercot a écrit :
> I've never delved into the nine circles of toolchain building and
> self-replication myself, because another guy has already done all the
> hard work: http://landley.net/aboriginal/
> (Yes, I do love that project. It's an awesome time-saver.)

     Yeah, Laurent. Rob Landley is great! But the last time I checked 
Aboriginal, porting to Musl was not finished yet - still problems with 
dynamic linking he says. I prefer Musl to uClibc for several reasons, 
because it seems to be the most POSIX-compliant of all, and because it's 
API is closer to Glibc, so that very few patches are necessary to 
compile applications developped for Glibc. This is why I finally 
bootstrapped my toolchain from 
https://github.com/sabotage-linux/sabotage . But, even in Sabotage, the 
compiler is not sysrooted :-( and, of course, in LFS, Aboriginal and 
Sabotage, can only compile C and C++ :-(

     Nevertheless, still checking Aboriginal from time to time, 
expecting the green light for Musl.

     Didier