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: Wed, 11 Jul 2018 15:13:40 +0200 Message-ID: <871sc9kj97.fsf@gnu.org> References: <8736wsnn6x.fsf@gnu.org> 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]:48467) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fdEwL-0003JY-NN for guix-devel@gnu.org; Wed, 11 Jul 2018 09:13:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fdEwK-0008W1-Dm for guix-devel@gnu.org; Wed, 11 Jul 2018 09:13:53 -0400 In-Reply-To: <8736wsnn6x.fsf@gnu.org> (Jan Nieuwenhuizen's message of "Mon, 09 Jul 2018 22:55:50 +0200") 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: Jan Nieuwenhuizen Cc: guix-devel@gnu.org, Rutger van Beusekom Hello Jan! Jan Nieuwenhuizen skribis: > With Mes 0.16 released I felt that after two years of straight hacking > I was pretty much done. Hmm... > > On the wip-bootstrap branch we have these packages > > binutils-2.20.1, gcc-2.95.3, and glibc-2.2.5 > > built without using any of these 3 main tools from the bootstrap > binaries. > > Using these we have built gcc-4.1.0 and glibc-2.3.6. I=E2=80=99ve said it before, but really: thumbs up to you and everyone at #bootstrapable for getting this far! It=E2=80=99s something that seemed li= ke a pipe dream not so long ago, so it=E2=80=99s really amazing that you made it= a reality. > And the above is an over-simplification, here's the list of seeds and > packages in order: > > %mescc-tools-seed > %mes-seed > %tinycc-seed > mescc-tools-boot > mes-boot > nyacc-boot > tcc-boot-0@0.9.26 > tcc-boot@0.9.27 > binutils-mesboot@2.20.1a > gcc-core-mesboot@2.95.3 > glibc-mesboot@2.2.5 > gcc-mesboot0@2.95.3 > binutils-mesboot@2.20.1a > gcc-mesboot@4.1.0 > [glibc-mesboot@2.3.6] Is tcc-boot a seed, or is it built from source using MesCC? > I hoped to get gcc-4.7.4 packaged easily but haven't succeeded in two > weeks. That means I'm stuck[0]. Much has happened: I'm helping to get > mescc-tools, Nyacc and Mes packaged in Debian, am writing some > documentation[1], got a preliminary hello-world on Hurd, worked on Gash[2] > to get it on par with bournish, applied for a GNU evaluation of Mes... Woow. > If we get gcc-4.7.4 built for x86 that's nice, but can we bootstrap > other architectures from that? Do we want that? We probably do not > want different bootstrap paths for different architectures. What > about the Hurd? I think that=E2=80=99s the main difficulty. I think we=E2=80=99d rather no= t have separate bootstrap paths for Intel GNU/Linux on one hand, and everything else on the other hand. 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.) Waiting for this to be =E2=80=9Csolved=E2=80=9D (and we don=E2=80=99t even = know how) would equate to a status quo. But obviously, it=E2=80=99d be sad to have all this work already done on Intel and not be able to benefit from it. So perhaps we=E2=80=99ll have to get over it and have a different bootstrap= path on x86-linux-gnu. (BTW, I suspect we can get away with using 32-bit bootstrap binaries on both i686/x86_64 and armv7/aarch64, no?) > That is why I've also been working on Gash--Guile As SHell--by > Rutger[cc] lately. If we make Gash powerful enough to replace bash to > build make and some of the other bootstrap binaries, that would be > nice. After a promising re-start it now proved that the heart of > Gash, the SH grammar in PEG and its subsequent transformations needs > an overhaul. That's being worked on but there is not much visible > progress. Gash seems to be a low-hanging fruit and a relatively easy thing, because it=E2=80=99s architecture-independent. How far is it from being able to run typical =E2=80=98configure=E2=80=99 script= s? I think the day it=E2=80=99s able to run =E2=80=98configure=E2=80=99 script= s, we can switch to it right away without further ado, and then incrementally improve it as we stumble upon limitations and bugs. WDYT? > So, where to go? Integrate the Mes x86 bootstrap and build other > architectures on top of that (is that even possible)? Add the Mes > bootstrap as an additional, weird `x86-linux' architecture to mature > first? Add other architectures to Mes and keep one bootstrap path in > Guix? Finish the x86 bootstrap/gcc-4.7.4 (I need help!)? If you=E2=80=99d like to take a break from the hardcode GCC bootstrap path = ;-), I think Gash for bootstrap is a good quickly-rewarding task. There=E2=80=99s also another option you didn=E2=80=99t mention: ditching th= e 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. 2. Same, but build Guile 2.x, libgc, etc. using MesCC. This could allow us to remove quite a lot of KiBs from our binary seeds. Thoughts? Thank you! Ludo=E2=80=99.