@civodul@ekaitz_zarraga@stikonas my idea was (is) to enhance mes lib c so that it can build gcc-4; but that's still in progress for x86, and riscv is "waiting" for that.
@civodul@ekaitz_zarraga@stikonas in any case, it's always much easier to change or enhance a working solution than to get it working in the first place.
@janneke@civodul@stikonas Using Musl is a very good compromise, too.
It's supereasy to read, and many of the problems we have fixed in meslibc we used musl as a reference so... Somehow meslibc is more similar to musl now. If we continue to do so, maybe it will become musl at some point hehe.
I think it’s great that you found a solution that works. For Guix at least, we also need to look at the bigger picture and see how to best address it with a whole-system approach.
To me that probably means tweaking Meslibc (which, of course, is easier said than done).
@civodul@ekaitz_zarraga@janneke Yes, tweaking mes would have required far bigger changes: rewrite all I/O there to use FILE structures, wide character strings and probably other things too. Anyway, it's just another package, not that much more different from GMP, MPFR or MPC that we also added.
@civodul@janneke As @stikonas says, musl is just another package.
Why does it feel right to add TinyCC but we prefer to avoid Musl?
In the same way it would be great to use MesCC to build GCC4.6.4 but that's not possible right now for two reasons: it would take forever to build and it needs many improvements in MesCC to make this possible.
Same thing happens with MeslibC. MeslibC is just very problematic at this very moment.
@janneke@ekaitz_zarraga@civodul Well, I guess the first point is similar to Xorg stuff. Xorg is also MIT but we do ship in in Guix. And both are GPL-compatible, so you can take a any improvements from musl and move to meslibc.
Hurd is a more interesting point. For real baremetal bootstrap neither Hurd nor Linux kernels are good anyway, you need something far simpler. But for userspace only bootstrap (as in Guix) that's definitely a valid point.
@janneke@ekaitz_zarraga@civodul Porting musl to Hurd might not be too hard. For x86 baremetal (from BIOS) bootstrap Rick Masters ported musl to Fiwix kernel with just a few patches.
That said I understand that you might still want to improve meslibc longer term even if it is harder.
@stikonas Is there a roadmap somewhere for baremetal (from BIOS) bootstrap like that? Where is any "real" OS coming into play in that? At witch point of bootstrapping story? @janneke@ekaitz_zarraga@civodul
@civodul@janneke@stikonas I shared in the past that it uses file descriptors as FILE structures, and that makes impossible to check if FILEs where opened correctly, it's not able to ungetc more than once and many things more. This makes binutils (not even GCC) impossible to build.
We need to rewrite many parts of MeslibC to make it able to build binutils, and probably way more for GCC.
@civodul@janneke@stikonas On the other hand, using Musl lets us avoid many intermediate steps and removes also many packages from the chain, as we can build more modern software directly.
It simplifies the chain, and that might doing more good than bad.
@ekaitz_zarraga@civodul@stikonas I'm happy with the progress and quite OK with using musl right now. I'd like to get rid of it again if we can, though.
@ekaitz_zarraga@civodul@stikonas both gnumach and the Hurd have gained 64bit support last year and gnumach just gained aarch64 support. Riscv shouldn't be all that hard when you or @pjotrprins decides they want it.
@janneke@ekaitz_zarraga@civodul@pjotrprins Anyway, the important thing is that there is a path. Replacing one component will be easier in the future as you know exactly what needs improving. When you work on the path for the first time, it's harder to tell whether you hit compiler, libc limitation or something else.
@stikonas@ekaitz_zarraga@civodul@pjotrprins I fully agree. And whether we port Musl to the Hurd/M2-Planet and drop Mes Lib C or enhance Me s Lib C and drop Musl really isn't all that interesting to me.
@ekaitz_zarraga@civodul@stikonas I've taken many shortcuts before and removed some of them later, others we're still in the process of removing. Removing (replacing?) the gcc-2.95 shortcut with a recent musl (shortcut?) is a big step forward to me.
Add comment