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