GNU bug report logs - #57127
unzip fails to cross-compile

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 57127 in the body.
You can then email your comments to 57127 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andrew Patterson <andrewpatt7 <at> gmail.com>
To: bug-guix <at> gnu.org
Subject: unzip fails to cross-compile
Date: Wed, 10 Aug 2022 18:06:35 -0400

[Message part 1 (text/plain, inline)]

unzip fails to build when cross-compiling (at least from x86_64 
linux), complaining that '%output' is unbound.  It gives identical 
errors when compiling for aarch64, riscv64, and arm. 
Interestingly, it gives the same errors when explicitly building 
for x86_64 on an x86_64 machine, even though I would expect doing 
so to compile as normal.  When not cross-compiling, unzip 
successfully builds as normal on both x86_64 and aarch64.

On my x86_64 machines, 'guix show unzip' does only have 
x86_64-linux and i686-linux in the 'systems' list, but that's also 
true of htop, which does cross-compile.  (Also, why does it do 
that?  The same command on my aarch64 machine shows many more 
system types.)

I'm working on testing if cross-compiling from aarch64 does the 
same thing, but building a cross-compilation toolchain on pinebook 
pro is very slow.

Steps to reproduce: run 'guix build unzip --target=$TARGET'

Here's the build log from 'guix build unzip 
--target=aarch64-linux-gnu':

[aa5q0nf3jklqj2f1ql18whrvlmm6k2-unzip-6.0.drv (text/plain, inline)]

WARNING: (guile-user): imported module (guix build utils) overrides core binding `delete'
Backtrace:
In ice-9/eval.scm:
   217:50 19 (lp (#<procedure 7ffff4b64c00 at ice-9/eval.scm:282:?> ?))
   217:50 18 (lp (#<procedure 7ffff4b64ba0 at ice-9/eval.scm:649:?> ?))
   217:50 17 (lp (#<procedure 7ffff4b64b80 at ice-9/eval.scm:282:?> ?))
   217:50 16 (lp (#<procedure 7ffff4b64b60 at ice-9/eval.scm:282:?> ?))
   217:50 15 (lp (#<procedure 7ffff4b64b40 at ice-9/eval.scm:282:?> ?))
   217:50 14 (lp (#<procedure 7ffff4b64b20 at ice-9/eval.scm:282:?> ?))
   217:50 13 (lp (#<procedure 7ffff4b64b00 at ice-9/eval.scm:282:?> ?))
   217:50 12 (lp (#<procedure 7ffff4b64980 at ice-9/eval.scm:649:?> ?))
   217:50 11 (lp (#<procedure 7ffff4b64960 at ice-9/eval.scm:282:?> ?))
   217:50 10 (lp (#<procedure 7ffff4b64940 at ice-9/eval.scm:282:?> ?))
   217:50  9 (lp (#<procedure 7ffff4b64920 at ice-9/eval.scm:282:?> ?))
   217:50  8 (lp (#<procedure 7ffff4b648c0 at ice-9/eval.scm:649:?> ?))
   217:50  7 (lp (#<procedure 7ffff4b648a0 at ice-9/eval.scm:282:?> ?))
   217:50  6 (lp (#<procedure 7ffff4b64880 at ice-9/eval.scm:282:?> ?))
   217:50  5 (lp (#<procedure 7ffff4b64860 at ice-9/eval.scm:282:?> ?))
   217:33  4 (lp (#<procedure 7ffff5fe9480 at ice-9/eval.scm:212:?> ?))
   213:45  3 (_ #f)
   196:43  2 (_ #f)
   223:20  1 (proc #<directory (guile-user) 7ffff5fdbc80>)
In unknown file:
           0 (%resolve-variable (7 . %output) #<directory (guile-use?>)

ERROR: In procedure %resolve-variable:
Unbound variable: %output

[Message part 3 (text/plain, inline)]

-- 
Andrew Patterson

Message #8 received at 57127 <at> debbugs.gnu.org (full text, mbox):

From: Andrew Patterson <andrewpatt7 <at> gmail.com>
To: 57127 <at> debbugs.gnu.org
Subject: Re: unzip fails to cross-compile
Date: Wed, 10 Aug 2022 20:45:59 -0400

[Message part 1 (text/plain, inline)]

Cross-compiling to x86_64 on aarch64 failed the same way.  Log 
below:

[rqgqcjd5vbm4jgxsda69xn38w3fw9x-unzip-6.0.drv (text/plain, inline)]

WARNING: (guile-user): imported module (guix build utils) overrides core binding `delete'
Backtrace:
In ice-9/eval.scm:
   217:50 19 (lp (#<procedure 7d93a0 at ice-9/eval.scm:282:4 (env)> ?))
   217:50 18 (lp (#<procedure 7d9340 at ice-9/eval.scm:649:6 (env)> ?))
   217:50 17 (lp (#<procedure 7d9320 at ice-9/eval.scm:282:4 (env)> ?))
   217:50 16 (lp (#<procedure 7d9300 at ice-9/eval.scm:282:4 (env)> ?))
   217:50 15 (lp (#<procedure 7d92e0 at ice-9/eval.scm:282:4 (env)> ?))
   217:50 14 (lp (#<procedure 7d92c0 at ice-9/eval.scm:282:4 (env)> ?))
   217:50 13 (lp (#<procedure 7d92a0 at ice-9/eval.scm:282:4 (env)> ?))
   217:50 12 (lp (#<procedure 7d9120 at ice-9/eval.scm:649:6 (env)> ?))
   217:50 11 (lp (#<procedure 7d9100 at ice-9/eval.scm:282:4 (env)> ?))
   217:50 10 (lp (#<procedure 7d90e0 at ice-9/eval.scm:282:4 (env)> ?))
   217:50  9 (lp (#<procedure 7d90c0 at ice-9/eval.scm:282:4 (env)> ?))
   217:50  8 (lp (#<procedure 7d9060 at ice-9/eval.scm:649:6 (env)> ?))
   217:50  7 (lp (#<procedure 7d9040 at ice-9/eval.scm:282:4 (env)> ?))
   217:50  6 (lp (#<procedure 7d9020 at ice-9/eval.scm:282:4 (env)> ?))
   217:50  5 (lp (#<procedure 7d9000 at ice-9/eval.scm:282:4 (env)> ?))
   217:33  4 (lp (#<procedure 6044c0 at ice-9/eval.scm:212:12 (en?> ?))
   213:45  3 (_ #f)
   196:43  2 (_ #f)
   223:20  1 (proc #<directory (guile-user) 5ebc80>)
In unknown file:
           0 (%resolve-variable (7 . %output) #<directory (guile-use?>)

ERROR: In procedure %resolve-variable:
Unbound variable: %output

[Message part 3 (text/plain, inline)]

-- 
Andrew Patterson

Message #11 received at 57127 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: Andrew Patterson <andrewpatt7 <at> gmail.com>, 57127 <at> debbugs.gnu.org
Subject: Re: bug#57127: unzip fails to cross-compile
Date: Thu, 11 Aug 2022 10:48:35 +0200

[Message part 1 (text/plain, inline)]

On 11-08-2022 00:06, Andrew Patterson wrote:
> unzip fails to build when cross-compiling (at least from x86_64 
> linux), complaining that '%output' is unbound.

Change #:make-flags to use a G-exp instead of a S-exp and replace the 
undocumented %output by the #$output.

For consistency, you can do the same for #:phases.

For simplicity, I recommend not using ` for argument but 'list': 
(arguments (list #:phases #~(modify-phases ...) #:make-flags #~(list ...))).

>   It gives identical errors when compiling for aarch64, riscv64, and 
> arm. Interestingly, it gives the same errors when explicitly building 
> for x86_64 on an x86_64 machine, even though I would expect doing so 
> to compile as normal.

Technically that's cross-compilation from Guix perspective, though maybe 
it should just compile natively in that case.


> On my x86_64 machines, 'guix show unzip' does only have x86_64-linux 
> and i686-linux in the 'systems' list, but that's also true of htop, 
> which does cross-compile.  (Also, why does it do that?  The same 
> command on my aarch64 machine shows many more system types.)

I don't know.

Greetings,
Maxime.

[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]

[OpenPGP_signature (application/pgp-signature, attachment)]

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: bug-guix <at> gnu.org, Andrew Patterson <andrewpatt7 <at> gmail.com>,
 57127 <at> debbugs.gnu.org
Subject: Re: bug#57127: unzip fails to cross-compile
Date: Thu, 11 Aug 2022 10:12:47 +0000

Hi Andrew,

This is a bug in Guix, not really related to cross-compiling (hence you can stop cross-testing and reporting different architectures, although the effort is appreciated!).

%output is practically deprecated, but is still present in a good number of packages.  Sometimes it happens to work, because a specific build system explicitly kept support for it.  Some build systems don't, making support for it feel unreliable.  It is.  %output is obsolete for new code.

What also happens is that build systems still support it in the well-tested native build path, but not when cross-compiling.  That seems to be the case here.

> Interestingly, it gives the same errors when explicitly building for x86_64 
> on an x86_64 machine, even though I would expect doing so to compile as normal.

You don't define what you mean by 'explicitly building'.

If you mean --target=x86_64-linux-gnu, why would it not fail?  You're cross-compiling.  Guix doesn't silently fall back to a non-cross build when the architectures match, no should it IMO.

The fix should be simple: rewrite unzip to use gexps and hence #$output.  Why didn't I simply do so yet?  Because too many packages depend on unzip to simply do so on master.  There's probably a way around that, but I'll try it when I'm back at a computer.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: bug-guix <at> gnu.org, Andrew Patterson <andrewpatt7 <at> gmail.com>,
 57127-done <at> debbugs.gnu.org
Subject: Re: bug#57127: unzip fails to cross-compile
Date: Thu, 11 Aug 2022 10:28:05 +0000

(Now home:) fixed in 45db0ca5e9.

Can you confirm that it works for you?

Closing,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

Message #28 received at 57127 <at> debbugs.gnu.org (full text, mbox):

From: Andrew Patterson <andrewpatt7 <at> gmail.com>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 57127 <at> debbugs.gnu.org
Subject: Re: bug#57127: unzip fails to cross-compile
Date: Thu, 11 Aug 2022 14:11:37 -0400

unzip now cross-compiles successfully.  Thank you!

-- 
Andrew Patterson

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.