Re: full-source bootstrap and Python

[Janneke Nieuwenhuizen]

Bruno Haible writes:

Hi!

> Janneke Nieuwenhuizen wrote:
>> Are are we creating a problem for
>> bootstrapping (or even a dependency cycle) when introducing this new
>> dependency into a certain package.
>
> I think you answered this question with "no", when writing in [1]:
>
>   "Even more recently (2018), the GNU C Library glibc-2.28 adds Python
>    as a build requirement"

How so?  In 2013, the GCC folks decided that their gcc-4.8 would no
longer be a directly bootstrappable compiler by introducing a (casual?)
dependency on c++.  That's pretty bad for bootstrapping, and it would be
amazing if someone could revet that mistake.  With glibc-2.28, a similar
bootstrappable mistake was made.

Making an essential GNU package such as GCC or Glibc non-bootstrappable
has severe consequences.  As an example, we have been working on the
RISC-V bootstrap for about a year with three people.  One of the
problems here is that RISC-V was only added to a non-bootstrappable
version of GCC: 7.5.0, while the GCC team failed to maintain their last
bootstrappable version: 4.7.4.  In other words, the RISC-V backend
needed to backported and someone else now needs to maintain a
bootstrappable version of GCC.

When something else like this changes in the future, that isn't as
"easily" backported, what do we do?  Terrible!

> So, how do you avoid Python when building glibc? Do you use musl libc as
> a first stage, and only build glibc once a python built with musl exists?

Currently we aren't directly hit by this because we build glibc-2.2.5
and glibc-2.16 first.  We added these earlier Glibc's because we allowed
ourcelves to cut some corners and there earlier versions were more easy
to bootstrap.  On the roadmap is to remove as many ancient versions as
we can, as they are potential time-bombs.  In fact, glibc-2.2.5 is
problematic for the ARM and the RISC-V bootstrap, so we'll get rid of
that.

We won't be able to get rid of advancing beyond glibc-2.27 without
adding a yet another non-GNU package such as musl libc.  Possibly a nice
hack for now, but what to do when we want to port the bootstrap to the
Hurd?  Again, terrible!

> Also, from the diagrams in [1][2][3] it looks like the full-source bootstrap
> uses tarballs frozen in time (make-3.80, gcc-2.95.3, gcc 4.7.3, etc.). So,
> even if newer versions of 'make' or 'gcc' will use a Python-based gnulib-tool,
> there won't be a problem, because the bootstrap of these old tarballs will
> be unaffected.

indeed.  For the current situtation (that's less than great and are
working on to resolve), making essential GNU packages less
bootstrappable is of no consequence.  Cleaning-up the full-source
bootstrap and making it more or less future-proof, might be challenged
by such a new dependency.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke@gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com