From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: bootstrap integration strategies Date: Thu, 12 Jul 2018 18:15:11 +0200 Message-ID: <874lh4toq8.fsf@gnu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fdeFd-0004KO-0y for guix-devel@gnu.org; Thu, 12 Jul 2018 12:15:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fdeFY-00018I-GB for guix-devel@gnu.org; Thu, 12 Jul 2018 12:15:28 -0400 In-Reply-To: (Jeremiah Orians's message of "Thu, 12 Jul 2018 12:16:03 +0000") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: "Orians, Jeremiah (DTMB)" Cc: "guix-devel@gnu.org" Hello OriansJ, "Orians, Jeremiah (DTMB)" 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 p= latforms Sounds nice. I wonder if Jan was referring to something else then? There=E2=80=99s still the question of GNU/Hurd, though, which requires a va= stly 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 boots= trapping 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 =E2=80=9Ccut=E2= =80=9D the source-to-binary connection by making those binaries the root of the dependency graph on these platforms. Maybe that=E2=80=99s something we=E2=80=99ll have to live with on new archi= tectures. >> 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 o= n non-x86 hardware (Knight platform to be precise) > And the engineering decisions involved where explicitly selected to minim= ize porting and cross-platform bootstrapping effort. > M1-macro and hex2-linker only need flags to be set to build for all of th= e different supported platforms So, problem solved? Or am I missing something? :-) I think the =E2=80=98wip-bootstrap=E2=80=99 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 cr= oss 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=E2= =80=99s been done on Mes, MesCC, M1, stage0, Gash, etc. Thanks for your feedback! Ludo=E2=80=99.