unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: "Orians, Jeremiah (DTMB)" <OriansJ@michigan.gov>
Cc: "guix-devel@gnu.org" <guix-devel@gnu.org>
Subject: Re: bootstrap integration strategies
Date: Thu, 12 Jul 2018 18:15:11 +0200	[thread overview]
Message-ID: <874lh4toq8.fsf@gnu.org> (raw)
In-Reply-To: <CY1PR09MB081148F46EEBBB4413DE0B6DC6590@CY1PR09MB0811.namprd09.prod.outlook.com> (Jeremiah Orians's message of "Thu, 12 Jul 2018 12:16:03 +0000")

Hello OriansJ,

"Orians, Jeremiah (DTMB)" <OriansJ@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’.

  reply	other threads:[~2018-07-12 16:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-12 12:16 bootstrap integration strategies Orians, Jeremiah (DTMB)
2018-07-12 16:15 ` Ludovic Courtès [this message]
2018-07-12 17:10   ` Orians, Jeremiah (DTMB)
2018-07-12 17:40   ` Jan Nieuwenhuizen
2018-07-12 19:52     ` Jan Nieuwenhuizen
2018-07-13 12:20     ` Ludovic Courtès
2018-07-13 14:19       ` Jan Nieuwenhuizen
2018-07-13 18:23       ` Ricardo Wurmus
2018-07-16 11:11         ` Orians, Jeremiah (DTMB)
2018-07-16 21:37           ` Brett Gilio
2018-07-12 17:44 ` Jan Nieuwenhuizen
  -- strict thread matches above, loose matches on Subject: below --
2018-07-09 20:55 Jan Nieuwenhuizen
2018-07-11 13:13 ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874lh4toq8.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=OriansJ@michigan.gov \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).