Re: bootstrap integration strategies

[Ludovic Courtès]

Hello Jan!

Jan Nieuwenhuizen <address@hidden> 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’ve said it before, but really: thumbs up to you and everyone at
#bootstrapable for getting this far!  It’s something that seemed like a
pipe dream not so long ago, so it’s 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
>     address@hidden
>     address@hidden
>     address@hidden
>     address@hidden
>     address@hidden
>     address@hidden
>     address@hidden
>     address@hidden
>     address@hidden

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’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.

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 “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.

So perhaps we’ll 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’s architecture-independent.  How
far is it from being able to run typical ‘configure’ scripts?

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.

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’d like to take a break from the hardcode GCC bootstrap path ;-),
I think Gash for bootstrap is a good quickly-rewarding task.

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.

  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’.