Hello OriansJ, "Orians, Jeremiah (DTMB)" <oria...@michigan.gov> skribis:
>> I think that's the main difficulty. I think we'd rather not have >> separate bootstrap paths for Intel GNU/Linux on one hand, and everything >> else on the other hand. > > Well, due to the design of mescc-tools; the bootstrap paths only have to be > divergent up to the M1-macro level. > After that, we could simply use flags make the source work on different > platforms Sounds nice. I wonder if Jan was referring to something else then? There’s still the question of GNU/Hurd, though, which requires a vastly different libc. >> Yet, we know that porting what you already did on x86-linux-gnu to >> GNU/Hurd and ARMv7 and AArch64 etc. is going to be a lot of non-trivial >> work (especially since historical versions of the GNU toolchain did not >> support AArch64, for instance.) > Nor RISC-V but that is likely to be a much bigger issue in terms of > bootstrapping So far the initial ports of Guix to non-x86 were done through cross-compilation (info "(guix) Porting"). So in a way, the binary seeds for these platforms were built from source; we just “cut” the source-to-binary connection by making those binaries the root of the dependency graph on these platforms. Maybe that’s something we’ll have to live with on new architectures. >> Waiting for this to be "solved" (and we don't even know how) would >> equate to a status quo. But obviously, it'd be sad to have all this >> work already done on Intel and not be able to benefit from it. > Actually the work for the stage0 bootstrap steps have already been done on > non-x86 hardware (Knight platform to be precise) > And the engineering decisions involved where explicitly selected to minimize > porting and cross-platform bootstrapping effort. > M1-macro and hex2-linker only need flags to be set to build for all of the > different supported platforms So, problem solved? Or am I missing something? :-) I think the ‘wip-bootstrap’ branch does not use M1 at this point, does it? [...] >> There's also another option you didn't mention: ditching the 2.0 >> bootstrap Guile in favor of Mes. That can be done in several steps: > >> 1. Replace the guile-2.0.*.xz binary tarballs with Mes, and add a step >> that builds Guile 2.x using our big bootstrap GCC binary. > Slow but possible > >> 2. Same, but build Guile 2.x, libgc, etc. using MesCC. > MesCC can't directly build Guile yet but I do enjoy that ambition ;-) I wonder what it would take to fix that. After all, compiling libguile must not be much harder than compiling tcc, no? > At this point, we effectively have a rope bridge to full bootstrappability > But we still have a lot of details to hammer out, like getting basic ARM > support and having the ARM and x86 binaries verify each other's bootstrap; > Finding 6502, z80, 8051, 68K, VAX, pdp11, Alpha, MIPS, SPARC and > PowerPC/Power Developer(s) to do stage0 work for their platforms and perform > the cross verify steps. > Hammer out cross-platform build details for MesCC and M2-Planet One thing at a time. :-) IMO what matters most at this point is to come up with a plan that allow us to incrementally reduce the size of our binary seeds. A port of M1/stage0 to Z80 can wait. ;-) So we really need a list of actionable items in the short term to start taking advantage of all the work that’s been done on Mes, MesCC, M1, stage0, Gash, etc. Thanks for your feedback! Ludo’.