I am confused. It is used only during check phase (which is build-time),
so when cross-compiling, the arch for build machine is used for
native-inputs right?
The Go build system doesn't support cross-compilation currently.
So, for explanation, let's assume gnu-build-system instead.
The issue is that, when cross-compiling, 'inputs' consists solely
of the packages listed in the 'inputs' field of the package definition
(When compiling natively, 'native-inputs' is merged into 'inputs'.)
As "coreutils" is not in "inputs", it follows that that (assoc-ref inputs
"coreutils")
returns #f. Thus, when (string-append (assoc-ref inputs "coreutils")
"/bin/sleep")
is executed, it raises an exception, as string-append expects strings only.
Now, about:
I am confused. It is used only during check phase (which is build-time),
so when cross-compiling, [...]
The [...]/bin/sleep binary is only used during the check phase (and therefore
ignored when cross-compiling), yes, but the (string-append [...]) is _always_
executed!
so when cross-compiling, the arch for build machine is used for native-inputs,
right?
Yes.
I wonder how other native-inputs like gettext etc doesn't give this error.
There's very little code doing (assoc-ref inputs "gettext"),
(assoc-ref native-inputs "gettext") or (assoc-ref native-inputs "gettext")
in Guix. The only case I found:
# cargo-build-system
(when (assoc-ref inputs "gettext")
(setenv "GETTEXT_SYSTEM" (assoc-ref inputs "gettext")))
So, I'm not sure what you're referring to.
Simply including gettext in native-inputs doesn't cause an error.
It it trying to (string-append (assoc-ref inputs "gettext") "stuff") that
raises an error when 'gettext' is not in 'inputs' or 'native-inputs' when
compiling natively,
or when 'gettext' is not in 'inputs' when cross-compiling,
as in these cases, (assoc-ref inputs "gettext") returns #f.
OpenPGP_signature