unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Josselin Poiret <dev@jpoiret.xyz>
To: guix-devel@gnu.org
Subject: Core-updates and cross-compilation
Date: Sat, 11 Mar 2023 13:56:27 +0100	[thread overview]
Message-ID: <877cvnigzo.fsf@jpoiret.xyz> (raw)

[-- Attachment #1: Type: text/plain, Size: 1999 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 682 bytes --]

             reply	other threads:[~2023-03-11 12:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-11 12:56 Josselin Poiret [this message]
2023-03-12 11:26 ` Core-updates and cross-compilation Andreas Enge
2023-03-14 17:48   ` Josselin Poiret
2023-03-14 19:54     ` Andreas Enge
2023-03-16 13:58 ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877cvnigzo.fsf@jpoiret.xyz \
    --to=dev@jpoiret.xyz \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).