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