bug#66866: Grafting breaks cross-compilation

["Ludovic Courtès" <ludo@gnu.org>]

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

Hi,

dan <i@dan.games> skribis:

> I spent some time digging into the rabbit hole.  After changing 
> the lower function of the copy-build-system to look more like the 
> lower function of the gnu-build-system, I'm able to cross compile 
> alsa-lib without the --no-grafts flag.  The changes I made are 
> like:
>
> diff --git a/guix/build-system/copy.scm 
> b/guix/build-system/copy.scm
> index d58931b33c..74304b4bfb 100644
> --- a/guix/build-system/copy.scm
> +++ b/guix/build-system/copy.scm
> @@ -66,13 +66,13 @@ (define* (lower name
>    (bag
>      (name name)
>      (system system)
> -    (host-inputs `(,@(if source
> +    (build-inputs `(,@(if source
>                           `(("source" ,source))
>                           '())
> -                   ,@inputs
> +                   ,@native-inputs
>                     ;; Keep the standard inputs of 
>                     'gnu-build-system'.
>                     ,@(standard-packages)))
> -    (build-inputs native-inputs)
> +    (host-inputs inputs)
>      (outputs outputs)
>      (build copy-build)
>      (arguments (strip-keyword-arguments private-keywords 
>      arguments))))
>
> Can we put everything inside build-inputs?  From my understanding, 
> copy-build-system shouldn't care about cross-compilation at all.

Intuitively, if ‘copy-build-system’ is about copying
architecture-independent files, then it should do the same thing whether
or not we are cross-compiling.

However, users can and do add phases whose result is
architecture-dependent.  Small sample:

  • ‘desec-certbot-hook’ captures a reference to curl, so it would get
    the wrong one when cross-compiling if we assumed build-inputs =
    host-inputs.

  • ‘chez-scheme-for-racket-bootstrap-bootfiles’ builds stuff when
    cross-compiling.  Philip, could you explain the intent and what you
    expect here?

So it would seem we can’t just assume everything is a native input like
https://issues.guix.gnu.org/70492 does.

Now, as David and you found out, the use of inputs in
build-system/copy.scm:lower is bogus.  It seems that it can be fixed by
following the intended definition of build/host inputs, as David
suggested:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 883 bytes --]

diff --git a/guix/build-system/copy.scm b/guix/build-system/copy.scm
index d58931b33c2..cf0214320bf 100644
--- a/guix/build-system/copy.scm
+++ b/guix/build-system/copy.scm
@@ -66,13 +66,13 @@ (define* (lower name
   (bag
     (name name)
     (system system)
-    (host-inputs `(,@(if source
+    (build-inputs `(,@(if source
                          `(("source" ,source))
                          '())
-                   ,@inputs
-                   ;; Keep the standard inputs of 'gnu-build-system'.
-                   ,@(standard-packages)))
-    (build-inputs native-inputs)
+                    ,@native-inputs
+                    ;; Keep the standard inputs of 'gnu-build-system'.
+                    ,@(standard-packages)))
+    (host-inputs inputs)
     (outputs outputs)
     (build copy-build)
     (arguments (strip-keyword-arguments private-keywords arguments))))

[-- Attachment #3: Type: text/plain, Size: 518 bytes --]


But wait! That’s all theoretical because the bag always has (target #f)
and ‘copy-build’ bundles build and host inputs together, as if doing a
native build.

So it seems like https://issues.guix.gnu.org/70492 (putting everything
in ‘build-inputs’) is OK, after all.

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.

Thoughts?

Ludo’.