Re: Core-updates and cross-compilation

[Ludovic Courtès]

Hi,

Josselin Poiret <dev@jpoiret.xyz> skribis:

> 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.

I agree with Andreas, I think that’s okay.

[...]

> - 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.

It’s really great that you’ve been looking at this!  If I can be of any
help, of if you feel desperate ;-), please don’t hesitate to ping me on
IRC.

>   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.

The good news is that Samuel Thibault is now officially a (actually:
the) Hurd maintainer, which means they should be able to get upload
permission to ftp.gnu.org—a step in the right direction.

> Should we consider these blockers for a core-updates merge?  Should we
> somehow stop supporting the first use-case?

In the past, I’d use ‘etc/release-manifest.scm’ as a way to check for
merge (or release) blockers.

When it comes to cross-compilation, we must be able to cross-compile the
bootstrap tarballs, as in:

  ./pre-inst-env guix build bootstrap-tarballs \
     --target=aarch64-linux-gnu -n

That works well on ‘core-updates’ so far, except for i586-pc-gnu.

Thanks,
Ludo’.