From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Orians, Jeremiah (DTMB)" Subject: Re: bootstrap integration strategies Date: Thu, 12 Jul 2018 12:16:03 +0000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35328) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fdaWr-0005kn-UF for guix-devel@gnu.org; Thu, 12 Jul 2018 08:17:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fdaWo-0003zk-Nq for guix-devel@gnu.org; Thu, 12 Jul 2018 08:17:01 -0400 Received: from coreosmtp1.michigan.gov ([136.181.192.169]:54324 helo=michigan.gov) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fdaWo-0003qh-Dy for guix-devel@gnu.org; Thu, 12 Jul 2018 08:16:58 -0400 Content-Language: en-US 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: "ludo@gnu.org" , "guix-devel@gnu.org" > 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 pla= tforms > 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 bootstr= apping > 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 minimiz= e 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 perhaps we'll have to get over it and have a different bootstrap path > on x86-linux-gnu. A multiway bootstrap path that exceeds the requirements of DDC actually > (BTW, I suspect we can get away with using 32-bit bootstrap binaries on > both i686/x86_64 and armv7/aarch64, no?) For AMD64, absolutely, ARM however I am not familiar enough to say > Gash seems to be a low-hanging fruit and a relatively easy thing, > because it's architecture-independent. How > far is it from being able to run typical 'configure' scripts? Well we would have to replace the parser at a bare minimum > I think the day it's able to run 'configure' scripts, we can switch to > it right away without further ado, and then incrementally improve it as > we stumble upon limitations and bugs. Well we only need Gash to get to the build make and bash level, after that = its scope can be limited. In theory, someone could hand replace the make build script with a custom v= ersion that gash can use right now instead of us enhancing gash > 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 ;-) > This could allow us to remove quite a lot of MiBs from our binary seeds. FTFY 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 su= pport and having the ARM and x86 binaries verify each other's bootstrap; Finding 6502, z80, 8051, 68K, VAX, pdp11, Alpha, MIPS, SPARC and PowerPC/Po= wer Developer(s) to do stage0 work for their platforms and perform the cros= s verify steps. Hammer out cross-platform build details for MesCC and M2-Planet Jeremiah Orians Cell phone: (517) 896-2948