simplifying rebootstrap - breaking hurd bootstrap?
Hi,
I intend to simplify the toolchain bootstrap for rebootstrap and this
has consequences for hurd.
The current linux/glibc toolchain bootstrap essentially works like this:
* cross binutils
* linux-libc-dev
* gcc stage1 cross compiler (baremetal)
* glibc stage1 (headers + stub libc.so)
* gcc stage2 cross compiler
* glibc stage2 (full libc without extra features such as systemtap)
* gcc stage3 cross compiler
* gcc rtlibs
The current linux/musl toolchain bootstrap is already simpler. It skips
"glibc stage1" and "gcc stage2" and directly builds the full musl using
the baremetal compiler. Quite a while ago, glibc was also converted to
support this sequence with fewer stages and this is what upstream's
build_many_glibcs.py does and what is tested. In Debian, we should
follow suit. And for everything except hurd-any, this seems to just
work.
The current hurd/glibc toolchain bootstrap seems to work like this:
* cross binutils
* linux-libc-dev
* gnumach stage1
* gcc stage1 cross compiler (baremetal)
* hurd stage1
* cross mig
* glibc stage1 (headers + stub libc.so)
* gcc stage2 cross compiler
* hurd stage2
* glibc stage2 (full libc without extra features such as systemtap)
* gcc stage3 cross compiler (including rtlibs)
When removing glibc stage1 and gcc stage2, we'll also have to somehow
merge the hurd stage1 and stage2. I have no clue how to do that.
To make matters worse, the hurd bootstrap is currently somewhat broken.
When using gcc-10, hurd stage3 fails due to -fno-commons (#955447,
fixed-upstream, thanks Samuel). When using gcc-9, I see an unpack error
for hurd-headers-dev which ships /usr/include/sys/procfs.h without
declaring a conflict with libc6-dev-i386. Last year, I saw a build
failure for hurd stage1. Not sure whether that is still present. In any
case, a flaky bootstrap sequence doesn't make working on this any
simpler.
Given the above, I want to move to the simplified toolchain bootstrap
sequence soon. It is unfortunate that doing so will break hurd, but I
believe that the benefits are more important. The roadmap roughly is:
* Some refactoring to ease transitioning to the new sequence.
* Add a flag REDUCED_TOOLCHAIN_BOOTSTRAP=yes/no to select the short or
long toolchain bootstrap. Everything but hurd-any will default to
yes.
* Some time later remove the long toolchain bootstrap sequence.
It would be very good if some hurd porters (e.g. busy Samuel) could
follow up on this mail. Keeping hurd support in rebootstrap requires
your effort. This is not urgent just yet, but I'd like to complete this
within a month.
As a first step, I suggest that someone (likely Samuel) replies to this
mail explaining why we presently need hurd stage1 and stage2 to be
separate. stage1 seems to skip libihash. Can we defer building libihash
until stage3? Can we build it in stage1? Is this the only difference
between stage1 and stage2?
Helmut
Reply to: