[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#47221: Guile not in native-inputs when it should
From: |
Maxime Devos |
Subject: |
bug#47221: Guile not in native-inputs when it should |
Date: |
Thu, 18 Mar 2021 10:29:59 +0100 |
User-agent: |
Evolution 3.34.2 |
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
signature.asc
Description: This is a digitally signed message part