guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#48729] [PATCH v2 05/47] gnu: Add go-github-com-keybase-go-ps.


From: Maxime Devos
Subject: [bug#48729] [PATCH v2 05/47] gnu: Add go-github-com-keybase-go-ps.
Date: Sat, 12 Jun 2021 18:21:53 +0200
User-agent: Evolution 3.34.2

Raghav Gururajan schreef op vr 11-06-2021 om 00:17 [-0400]:
> Hi Maxime!
> 
> > When cross-compiling, coreutils is not in 'inputs', but in 'native-inputs', 
> > right?
> > So this would lead to a build error when cross-compiling.
> > (assoc-ref inputs "coreutils") would return #f, thus you'd get an exception
> > 
> > ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> > In procedure string-append: Wrong type (expecting string): #f
> 
> 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.

Greetings,
Maxime.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]