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

[Ruud Koolen]

On Sunday 02 February 2014 10:04:39 Fabian Groffen wrote:
> 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.

Can you elaborate? As far as I know, gmp/mpfr/mpc will compile everywhere 
(unlike, say, glibc, which really does have a recent-gcc dependency). Can you 
give a specific example of these libraries not compiling on any platform 
prefix supports?

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

Nice.

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

We'll see :)

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

But gcc and friends are specifically designed to be buildable on any 
ridiculous old system, and the use of other tools hasn't changed between my 
bootstrap process and the current one. Again, can you elaborate and give a 
concrete example?

-- Ruud