Hi Ludo’!

Out of curiosity, how does musl help on the path?  I’m guessing the fact
that it doesn’t used nested functions (from GNU C) makes it more
amenable to compilation with a simpler compiler, but maybe there’s
something else?

I took inspiration by the live-bootstap project, it seemed easier to use musl.  
And compare the dependencies of musl and glibc.

musl¹
    (native-inputs (inputs-with-shell GASH-bootstrap
                                      MAKE-MES-bootstrap
                                      GASH-UTILS-bootstrap
                                      BOOTAR-bootstrap))

glibc²
    (native-inputs (inputs-with-shell BASH-bootstrap
                                      GZIP-bootstrap
                                      GREP-bootstrap
                                      GAWK-bootstrap
                                      PYTHON-bootstrap
                                      GCC-15-bootstrap
                                      TAR-bootstrap
                                      BINUTILS-bootstrap
                                      BISON-bootstrap
                                      GETCONF-bootstrap
                                      COREUTILS-bootstrap
                                      SED-bootstrap
                                      MAKE-bootstrap))
    and $LINUX-HEADERS-bootstrap

True, some tools may be replaceable, like tar and gzip with Bootar and 
Gash-Utils.  But already sed from Gash-Utils is not sufficient, neither awk.  
And Python is a real blocker, static builds seem not to be supported anymore in 
3.13.7.  All these dependencies need a C library (even dynamic linking) and the 
one from Mes is really limited.

Make still builds with Mes, but I remember that I ran into issues related to 
stubs in the Mes C library with some next package – I think it was bash.

It doesn't seem meaningful to me to travel back in time for every package, 
looking for an old version, which may still build with the Mes C library.  Any 
such old package could force the next package in the chain to be downgraded as 
well, just because of missing functionality.  That could become kind of a 
downgrade loop, increasing the total number of packages.  And any problem on 
the way could be related to too old package versions with a missing 
functionality or a bug – recursively down the chain to a stub or bug in the Mes 
C library.

I'm convinced that a mature C library with least possible dependencies is the 
key for a short bootstrap chain.

So no, the nested functions haven’t even had a chance to become an obstacle.

By the way, there is one such downgrade case³: GCC 4 (newer versions require a 
C++ compiler) produces object files, which let ld of Binutils 2.43 crash.  So 
because of GCC 4, Binutils is downgraded to 2.42. (Hm, that's already a while 
ago, I should recheck this with 2.45.)


Bye

Stefan


¹ 
<https://git.pub.solar/stefan/embedded-channel/src/commit/597fcbec2332c7b1f9a568ba4ccf53a12384d8ac/gcc-bootstrap.scm#L2713>
² 
<https://git.pub.solar/stefan/embedded-channel/src/commit/597fcbec2332c7b1f9a568ba4ccf53a12384d8ac/gcc-bootstrap.scm#L5513>
³ 
<https://git.pub.solar/stefan/embedded-channel/src/commit/597fcbec2332c7b1f9a568ba4ccf53a12384d8ac/gcc-bootstrap.scm#L3533>

Reply via email to