Re: [gentoo-alt] Restructuring the bootstrap (or: getting rid of gcc 4.2)

[Fabian Groffen]

On 02-02-2014 03:31:51 +0100, Ruud Koolen wrote:
> This process avoids the problem of host-built libraries, as it makes a sharp
> distinction between host-built code and prefix-built code; all host-built code
> goes in $EPREFIX/tmp, and all prefix-built code goes in $EPREFIX. This means
> there is nothing stopping us from using libraries in the host-built code;
> host-built libraries end up in $EPREFIX/tmp, and only host-built binaries (and
> libraries) will link to it, so ABI incompatibilities aren't a problem. Thus,
> the latest version of gcc and friends can be used, avoiding many problems.
> Similarly, the $EPREFIX/tmp toolchain can build $EPREFIX libraries without
> problems.

I'm affraid you don't quite understand why the bootstrap uses older gcc
versions.  On non Linux platforms (what bootstrap-prefix.sh is tuned
towards) newer versions of gcc require libs (as you noted) that require
newer gcc versions than the host toolchain provides.  So, you simply
cannot compile later versions with the tools you've got, hence you'll
have to carefully go up in steps until your toolchain has been upgraded
enough to compile the beautiful tools and libraries we like to have.

> As far as I can see, the advantages of my bootstrap method are as follows:
> - It gets rid of all reliances on old package versions, and gcc in particular.

As pointed out above, impossible to remove.

> As explained above, gcc 4.2 has bugs that won't be fixed that are causing
> actual practical problems (#262653, #490774), and has a dated set of supported

I'm fine with lifting the limits for platforms that provide the
necessary up-to-date tools somehow.

> architectures (which was causing problems in supporting newer android
> systems); and in general, old packages have a nasty tendency to bitrot, making
> things unnecessarily flaky (bash-4.0 and 4.1 accidentally got removed from the
> tree recently, breaking the bootstrap).

I've fixed the odd bash dependency yesterday.  I removed some hacks as
well which were no longer necessary.  A bootstrap on x86-solaris
succeeded after my fixes.

> - It keeps the final prefix clean. The current process bootstraps a portage
> into $EPREFIX, and overwrites it later with a portage-built portage; these two

The only pollution should be portage + bash symlink.

> portages need to be the exact same version, or old junk will end up in the
> prefix that doesn't belong to any package, which can go wrong if using
> LATEST_TREE_YES. In my process, nothing ever ends up in $EPREFIX that portage
> didn't put there. Together with my earlier work to get rid of the stage2
> profile hackery, this will keep $EPREFIX completely pollution-free.

I doubt it can be.

> - It gets rid of a large part of the stage3 hacks, most of which are due to
> either mixing of $EPREFIX/tmp and $EPREFIX or gcc 4.2.

stage3 currently is a careful ordered emerge process (little to no
hacks, apart from getting dependencies ignored), syncing the tree,
upgrading gcc to latest, and emerging everything from system that hasn't
been installed yet.

> - No, it doesn't need to build more compilers than the current method. The
> current bootstrap proces builds gcc4.2, upgrades to gcc 4.7 (or something),
> and rebuilds it during emerge -e @system; my process builds a gcc in
> $EPREFIX/tmp, uses it to build a gcc in $EPREFIX, and rebuilds it during
> emerge -e @system.
>
> I propose adopting this new bootstrap system for prefix, both in order to
> improve the regular prefix bootstrap process, and to allow RAP work to
> continue (which, by the way, is nearing the end of the road). I have an
> almost-completely-working(1) implementation of it at the ready (2); when it's
> properly ready in a few days, if you all agree, I want to emit a call-for-
> testing to make sure it actually works as promised on all platforms (the only
> one for which I have been able to do proper testing so far is linux), and get
> it operational.
>
> What say you, prefix people? Is this the proper way forward?

I'm not against this, but I think hacks will have to remain in order to
allow Darwin and Solaris (amongst others) targets to stay working.  In
particular the case of outdated tools is something you seem not to take
into account, which severly limits your options.

Fabian


-- 
Fabian Groffen
Gentoo on a different level