bug#47221: Guile not in native-inputs when it should

[Maxime Devos <maximedevos@telenet.be>]

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

On Wed, 2021-03-17 at 22:58 +0100, Maxime Devos wrote:
> [...]
> Some suspicious things:
> * [...]
> * clipmenu & others use "wrap-script" to define wrapper scripts

>   (in this case "guile" does not have to be in native-inputs).
>   The "wrap-script" procedure from (guix build utils) uses the
>   "which" procedure to determine where guile is located ...
>   but this is incorrect when cross-compiling!

Demonstration (host system: x86-64-linux with a childhurd running, without qemu binfmt),
using the "bats" package (the "bats" package is choosen because it doesn't have many
dependencies and it uses wrap-script).  ("bats" actually uses wrap-script correctly,
so first remove the following line
                                ":" (assoc-ref %build-inputs "guile") "/bin"
from the package definition to simulate a misbehaving package)

./pre-inst-env guix build --system=i586-gnu --target=x86-64-linux bats
--> tcl fails to build with plenty of failing test cases
^ TODO submit a bug report, for now try without tests

./pre-inst-env guix build --system=i586-gnu --target=x86-64-linux bats --without-tests=tcl
^ TODO this hangs the childhurd (something about paging?)

./pre-inst-env guix build --target=aarch64-linux bats
(warning: this takes some time building the cross-compiler)
--> install.sh: line 15: /gnu/store/...-coreutils-8.32/bin/install: cannot execute binary file: Exec format error

After adding "coreutils" to the native-inputs:

./pre-inst-env guix build --target=aarch64-linux bats
(success! --> some /gnu/store/something path $STORE_ITEM)

Let's look at $STORE_ITEM/bin/bats:

(start snip)
#!#f --no-auto-compile
#!#; Guix wrapper
#\-(begin (let ((current (getenv "PATH"))) (setenv "PATH" (if current (string-append "/gnu/store/qrj2w7a8ms7rkyvqhnrv8wrvqnbwv9bm-bash-
5.0.16/bin:/gnu/store/n8awazyldv9hbzb7pjcw76hiifmvrpvd-coreutils-8.32/bin:/gnu/store/3xi5vprn92r0jcb03lk9ykind5pi789j-grep-3.4/bin:/path-
not-set" ":" current) "/gnu/store/qrj2w7a8ms7rkyvqhnrv8wrvqnbwv9bm-bash-5.0.16/bin:/gnu/store/n8awazyldv9hbzb7pjcw76hiifmvrpvd-coreutils-
8.32/bin:/gnu/store/3xi5vprn92r0jcb03lk9ykind5pi789j-grep-3.4/bin:/path-not-set"))))
#\-(let ((cl (command-line))) (apply execl "/gnu/store/qrj2w7a8ms7rkyvqhnrv8wrvqnbwv9bm-bash-5.0.16/bin/bash" (car cl) (cons (car cl)
(append (quote ("")) cl))))
#!/gnu/store/qrj2w7a8ms7rkyvqhnrv8wrvqnbwv9bm-bash-5.0.16/bin/bash

set -e

BATS_READLINK='true'
[...]
(end snip)

I was worried for a moment that the inputs in "inputs" would contribute to
$PATH even when cross-compiling, but this turns out not to be the case.
However, I believe "wrap-script" should raise some kind of exception
instead of trying to use "#f" as interpreter.

--
Btw., "wrap-program" also uses "which" (but for finding the shell),
but fixing that would entail a world-rebuild as "wrap-program" doesn't
have a keyword argument

> Greetings,
> Maxime

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]