unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: David Elsing <david.elsing@posteo.net>
To: "Ludovic Courtès" <ludo@gnu.org>, dan <i@dan.games>
Cc: dev@jpoiret.xyz, Philip McGrath <philip@philipmcgrath.com>,
	Mathieu Othacehe <othacehe@gnu.org>,
	efraim@flashner.co.il, 70492@debbugs.gnu.org,
	66866@debbugs.gnu.org, janneke@gnu.org
Subject: [bug#70492] bug#66866: Grafting breaks cross-compilation
Date: Sun, 12 May 2024 15:39:32 +0000	[thread overview]
Message-ID: <86o79byr7v.fsf@posteo.net> (raw)
In-Reply-To: <8734r143fv.fsf_-_@gnu.org>

Hello,

I think I finally understand why the problem only occurs with grafts if
a dependency uses copy-build-system. It is actually somewhat
complicated.

When a package is lowered into a derivation by 'package->derivation' in
guix/packages.scm, a list of potentially applicable grafts is created by
the 'bag-grafts' procedure.
This works by first traversing the bag for native packages (where
bag-build-inputs and bag-target-inputs are followed recursively; and
also bag-host-inputs if not cross building) and building the native
derivations of the grafted versions of the packages which have a
replacement (such as glibc at the time of writing). Building the grafted
package (in the 'input-graft' procedure) is done again with
'package->derivation', which eventually calls 'graft-derivation' in
guix/grafts.scm, which in turn calls 'non-self-references', where the
ungrafted package is actually built (ignoring the store monad
indirection), not just its derivation.
In the case of cross builds, the bag is also traversed for the target
dependencies, where the bag-host-inputs are followed recursively.
Analogously, this causes the ungrafted packages and their ungrafted
replacement to be cross built to compute the grafted derivations.

As dan found out, the 'lower' procedure in guix/build-system/copy.scm
incorrectly puts standard-packages into the host inputs. They contain
the glibc-final package in gnu/packages/commencement.scm (which inherits
the replacement of glibc). Because copy-build-system puts them into
bag-host-inputs, the package replacement of the glibc-final package is
then cross built without grafts when calculating its grafted derivation,
which it does not support. Note that the glibc-final package and its
package replacement are distinct from the glibc package and its
replacement in gnu/packages/base.scm. I confirmed this by running
--8<---------------cut here---------------start------------->8---
,use (guix)
(with-store store (run-with-store store (package->cross-derivation (package-replacement (@@ (gnu packages commencement) glibc-final)) "i686-linux-gnu" #:graft? #f)))
--8<---------------cut here---------------end--------------->8---
in the REPL, which returns the same incorrect glibc derivation that is
attempted to be built as a dependency when running
`guix build alsa-lib --target=i686-linux-gnu`.

It is actually possible to compute the graft derivations only when
needed by a store reference (which does not change the derivation of the
grafted package). Then, this problem does not occur even without the fix
for the copy-build-system, as the invalid derivations are never actually
built. With substitutes or after running GC, this may even prevent
building a package with replacement when the requested package output
which (transitively) depends on it has no (transitive) store reference
to it. I made a patch for that here: https://issues.guix.gnu.org/70895

Regarding the changes to the copy-build-system:

Ludovic Courtès <ludo@gnu.org> writes:

> But still, there seem to be some expectation that ‘copy-build-system’
> can support cross-compilation for real, so maybe we should add a
> ‘copy-cross-build’ procedure in addition to the patch above.

In guix/build-system/copy.scm, it is described as an extension of
gnu-build-system and the manual says "It adds much of the
gnu-build-system packages to the set of inputs. Because of this, the
copy-build-system does not require all the boilerplate code often needed
for the trivial-build-system."
Therefore, I think it makes sense to add the copy-cross-build procedure
so that copy-build-system actually behaves like gnu-build-system.

Cheers,
David




           reply	other threads:[~2024-05-12 15:40 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <8734r143fv.fsf_-_@gnu.org>]

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=86o79byr7v.fsf@posteo.net \
    --to=david.elsing@posteo.net \
    --cc=66866@debbugs.gnu.org \
    --cc=70492@debbugs.gnu.org \
    --cc=dev@jpoiret.xyz \
    --cc=efraim@flashner.co.il \
    --cc=i@dan.games \
    --cc=janneke@gnu.org \
    --cc=ludo@gnu.org \
    --cc=othacehe@gnu.org \
    --cc=philip@philipmcgrath.com \
    /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).