On 2025-09-03 22:03, Stefan wrote:
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>
We (stikonas and I) reached a similar conclusion when working on RISC-V
for live-bootstrap. Musl is way simpler and it's easy to compile.
The main issue it has is it doesn't support the Hurd, and porting it to
the Hurd is not obvious. It's a shame, but I think the move to Musl at
least for the bootstrapping is the best we can do right now, specially
on RISC-V.
Cheers,
Ekaitz
