Hi, On 2020-04-15 22:58, Helmut Grohne wrote: > Source: cross-toolchain-base > Version: 45 > Severity: wishlist > Tags: patch moreinfo > > I'm not sure anymore who told me, but glibc has a build_many_glibcs.py > script and it does the toolchain bootstrap dance with fewer stages than > Debian (i.e. cross-toolchain-base and rebootstrap) does.
Yes, this is what upstream is doing for the build bots. It's also the recommended sequence for bootstrapping a system. > The current > Debian toolchain bootstrap looks like this: > > * binutils > * linux-libc-dev > * gcc stage1 (bare metal) > * glibc stage1 (headers + stub libc.so) > * gcc stage2 > * glibc stage2 (libc without systemtap and other optional features) > * gcc stage3 (libc-integrated cross compiler) > * gcc rtlibs (runtime libraries for the cross compiler) > > The assertion is that we can skip glibc stage1 and gcc stage2 and go > directly from gcc stage1 to glibc stage2. > > I've implemented this in rebootstrap and it seems to work reasonably > well for a number of architectures. I've not run it on the full test > matrix yet. Some observations on rebootstrap: > * musl-linux-any already works like this since a while. > * hurd-any formerly needed libihash-dev for libpthread, but no longer > does. This sequence also works on hurd-i386. > * I've had success with arm64, armel, armhf, m68k, mips (nobiarch), > mipsel (nobiarch) and ppc64el thus far. Notably, these all lack > multilibs and I'm still sorting out multilib issues. > * I cannot tell about kfreebsd-any, since they didn't manage to get the > relevant kernel header source package back into unstable yet. > > I've implemented this for cross-toolchain-base (patch attached) and a > performed a successful testbuild. Using diffoscope to compare the > resulting packages with the ones from the archive was not a useful thing > to do as the build-ids changed. Thanks a lot for working on that. I haven't tried it but that's great news. > So what do you think about going to fewer stages? I'd like to solicit > explicit feedback from the involved parties: > > gcc maintainers / Matthias: > * Do you have any objections to reducing stages? > * Should we delete gcc stage2? > * Should we rename gcc stage3 to gcc stage2? > > glibc maintainers / Aurelien: > * Do you have any objections to reducing stages? I have no objections for that. I am actually really in favor for that. We have less chances to have issues if we stick to the upstream recommended way of bootstrapping. And if we find issue, it will be easier to fix them and get those fixes upstreamed. > * Should we delete glibc stage1? Not immediately, we should keep it for a few weeks or months to make sure all works as expected. > * Should we rename glibc stage2 to glibc stage1? That's probably a good idea, in a second step. > * Should we maybe split stage2 into a number of profiles > pkg.glibc.noselinux, pkg.glibc.noxen, pkg.glibc.noalphaev, > pkg.glibc.noxcryptdep? That's an option, I don't have a strong opinion at that point. I guess that pkg.glibc.noalphaev and pkg.glibc.noxcryptdep can actually be merged into a single profile to disable optimized builds. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://www.aurel32.net
signature.asc
Description: PGP signature
