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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
