Hi everyone, I've been looking at the state of most failures for the CI jobset for core-updates, and we have a couple of problems:
- gcc < 9 and gcc == 12 never cross-compile. This is because we just don't do the right thing: suppose I have by default GCC version X (here 11) and I want to cross-compile a GCC version Y. What we do is, we first a GCC version X cross-compiler (as part of the default toolchain used when cross-compiling), then cross-compile GCC version Y and then cross-compile its supporting libraries. This doesn't work because the supporting libraries might use features only available in the same GCC version. In the native case, the supporting libraries are built with the new compiler! What we should do instead is build a GCC version Y cross-compiler and use that to build the cross-compiled GCC. This will require non-trivial changes, since we'd need to specify in the package definition of gcc-12 that it needs to be cross-compiled by ... gcc-12 :/ gcc version between 9 and 11 work by sheer luck. - we can't build the cross toolchain for the hurd, because the glibc upgrade to 2.35 would require newer gnumach headers, itself with a newer mig. All these upgrades would be local and pretty ok if they didn't also require a glibc patch to make the configure script of glibc work (right now it would check for presence of headers without -ffreestanding, even though we clearly don't have the glibc built yet!). This would cause a world-rebuild as well. I don't know how much work fixing the rest would be, but that's probably the only glibc patch that's needed. Also note that Hurd now seems to have some quite recent git tags, which are also used by Debian, so we can expect less random commit combinations not working. Should we consider these blockers for a core-updates merge? Should we somehow stop supporting the first use-case? WDYT? Best, -- Josselin Poiret
signature.asc
Description: PGP signature