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
