Compilation error on git master: `gzip: unbound variable`

Done

Details

5 participants

Chris Marusich
Ludovic Courtès
Marius Bakke
Mark H Weaver
pkill9

Owner: unassigned

Submitted by: pkill9

Severity: important

Debbugs page

pkill9 wrote 7 years ago

Recipients:(name . bug-guix)(address . bug-guix@gnu.org)

Message-ID:E1eRODH-0006TY-Pl@rmmprod07.runbox

Architecture: x86_64

RAM: 4GB

Filesystem: EXT4

Guile version: 2.0.11

Guile-Git (Guile module) was manually compiled and installed by me from
https://gitlab.com/guile-git/guile-git

Operating system: Slackware 14.2

`uname -a` output: Linux slack 4.4.88 #2 SMP Thu Sep 14 14:21:06 CDT 2017
x86_64 Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz GenuineIntel GNU/Linux


Compilation failure when running `make` (after running `./bootstrap` and
`./configure`) in latest git master and in latest source release tarball:
'In procedure memoize-variable-access!: gzip: unbound variable'

Full output (error is at line 172): http://paste.debian.net/1001510

My IRC username on freenode is pkill9, I am often in the #guix room on
freenode.

IRC chatlog for reference:

  2017-12-19 16:39:05 pkill9 I'm getting an error while compiling Guix,
  It
  says 'In procedure memoize-variable-access!: gzip: unbound variable'.
  Full output here: https://pastebin.com/wiNSZvXT
  2017-12-19 16:39:15 pkill9 anyone know what this means?
  2017-12-19 16:40:15 civodul pkill9: this was reported a couple of
  times
  before and i think it's been fixed (?)
  2017-12-19 16:40:26 pkill9 oh interesting
  2017-12-19 16:40:38 civodul can you paste to another site BTW, like
  paste.debian.net, which allows Tor users to access it
  2017-12-19 16:40:42 pkill9 ok
  2017-12-19 16:42:37 pkill9 http://paste.debian.net/1001510/
  2017-12-19 16:43:09 pkill9 I downloaded the source from the Guix
  downlaod
  page
  2017-12-19 16:46:24 pkill9 civodul: has the fix been added to the
  source
  downloadable from the download page?
  2017-12-19 16:46:51 pkill9 as in on this page
  https://www.gnu.org/software/guix/download/
  2017-12-19 16:47:03 pkill9 under 'GNU Guix 0.14.0 Source'
  2017-12-19 16:47:09 pkill9 in the tarball
  2017-12-19 16:47:28 pkill9 or is it very new and not yet been added
  to
  that?
  2017-12-19 16:51:18 bavier pkill9: iirc it was a more recent fix
  2017-12-19 17:02:20 civodul yes, it's in master i think
  2017-12-19 17:02:47 civodul though i still can't remember what that
  was,
  which is kinda annoying
  2017-12-19 18:57:21 lfam pkill9: From commit
  9a56cf2b5b4970843c215091ea9823a67e077310, the error is not
  reproduced.
  2017-12-19 19:08:54 pkill9 hmm i tried compiling with that commit
  (downloaded the tar.gz from
  https://git.savannah.gnu.org/cgit/guix.git/commit/?id=9a56cf2b5b4970843c215091ea9823a67e077310)
  and i still get that error
  2017-12-19 19:14:24 lfam pkill9: What is `guix --version`?
  2017-12-19 19:14:51 pkill9 i don't have it installed, that's why i'm
  compiling it
  2017-12-19 19:15:19 lfam How are you providing the dependencies?
  2017-12-19 19:15:39 pkill9 oh, slackware
  2017-12-19 19:16:03 lfam Okay, and what is the CPU architecture, how
  much
  RAM is there, what filesystem are you compiling on, any other details
  that might be relevant?
  2017-12-19 19:16:11 lfam Also the kernel version
  2017-12-19 19:17:18 pkill9 x86_64, about 4GB ram, EXT4 filesystem,
  kernel
  4.4.88
  2017-12-19 19:18:28 lfam pkill9: Okay, that all sounds good. What
  version
  of Guile are you using?
  2017-12-19 19:18:42 pkill9 2.0.11
  2017-12-19 19:20:05 lfam Okay, sounds like this should all work. If
  you
  don't get any other answer here, please compile all this information
  into
  a bug report and send it to <bug-guix@gnu.org>, first searching for
  previous reports of
  this issue

Attachment: file

Marius Bakke wrote 7 years ago

Recipients:(address . pkill9@runbox.com)(address . 29774@debbugs.gnu.org)

Message-ID:878tdmd9rf.fsf@fastmail.com

pkill9@runbox.com writes:

Toggle quote (23 lines)> Architecture: x86_64
>
> RAM: 4GB
>
> Filesystem: EXT4
>
> Guile version: 2.0.11
>
> Guile-Git (Guile module) was manually compiled and installed by me from
> https://gitlab.com/guile-git/guile-git
>
> Operating system: Slackware 14.2
>
> `uname -a` output: Linux slack 4.4.88 #2 SMP Thu Sep 14 14:21:06 CDT 2017
> x86_64 Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz GenuineIntel GNU/Linux
>
>
> Compilation failure when running `make` (after running `./bootstrap` and
> `./configure`) in latest git master and in latest source release tarball:
> 'In procedure memoize-variable-access!: gzip: unbound variable'
>
> Full output (error is at line 172): http://paste.debian.net/1001510

This paste has expired. Can you attach the log here instead?

pkill9 wrote 7 years ago

Recipients:(name . Marius Bakke)(address . mbakke@fastmail.com)(name . 29774)(address . 29774@debbugs.gnu.org)

Message-ID:E1eUhOh-0001lp-1S@rmmprod06.runbox

Attachment: file

Chris Marusich wrote 7 years ago

Recipients:(address . pkill9@runbox.com)(address . 29774@debbugs.gnu.org)(name . Marius Bakke)(address . mbakke@fastmail.com)

Message-ID:874ln6s34t.fsf@garuda.local.i-did-not-set--mail-host-address--so-tickle-me

<pkill9@runbox.com> writes:

Toggle quote (36 lines)>> Compiling Scheme modules...
>>
>> ...
>>
>>   LOAD     guix/scripts/pack.scm
>> Backtrace:
>> In ice-9/r4rs.scm:
>>   90: 19 [dynamic-wind #<procedure 1744360 at ice-9/eval.scm:416:20 ()> ...]
>>   90: 18 [dynamic-wind #<procedure 17442d0 at ice-9/eval.scm:416:20 ()> ...]
>> In ice-9/eval.scm:
>>  432: 17 [eval # #]
>>  432: 16 [eval # #]
>>  481: 15 [lp (#<fluid 16>) (#<output: void 11b7a90>)]
>> In ice-9/boot-9.scm:
>> 2864: 14 [resolve-interface (guix scripts pack) #:select ...]
>> 2789: 13 [#<procedure 1381ae0 at ice-9/boot-9.scm:2777:4 (name #:optional autoload version #:key ensure)> # ...]
>> 3065: 12 [try-module-autoload (guix scripts pack) #f]
>> 2401: 11 [save-module-excursion #<procedure 69daed0 at ice-9/boot-9.scm:3066:17 ()>]
>> 3085: 10 [#<procedure 69daed0 at ice-9/boot-9.scm:3066:17 ()>]
>> In unknown file:
>>    ?: 9 [primitive-load-path "guix/scripts/pack" ...]
>> In ice-9/eval.scm:
>>  453: 8 [eval # ()]
>>  387: 7 [eval # ()]
>>  387: 6 [eval # ()]
>>  387: 5 [eval # ()]
>>  387: 4 [eval # ()]
>>  387: 3 [eval # ()]
>>  387: 2 [eval # ()]
>>  393: 1 [eval #<memoized gzip> ()]
>> In unknown file:
>>    ?: 0 [memoize-variable-access! #<memoized gzip> #<directory # 6d10bd0>]
>>  
>> ERROR: In procedure memoize-variable-access!:
>> ERROR: gzip: unbound variable

I can reproduce this error when attempting to build Guix 0.14.0 from

source, using system-provided and custom built dependencies. I cannot

reproduce it when using Guix-provided dependencies (e.g., by running

'guix environment guix' and then manually building it).

I may have a work-around for you. Let me know if it works. Please try

the following:

1) Run a command like "make V=1". Because Guix uses GNU Automake, you

can get verbose output by adding "V=1" to the command ((automake)

Automake Silent Rules). This will cause make to print the commands that

are being run.

2) Find the exact "compile-all.scm" invocation being used (it should

appear right after the string "Compiling Scheme modules..." in the build

output). Copy it and run it manually from the root of the build

directory (i.e., the directory containing the "configure" script), but

instead of passing it all the .scm files, only pass it the single file

guix/scripts/pack.scm.

3) If (2) succeeds in building the pack.go file, try running "make"

again. Because the pack.go file is newer than the pack.scm file, it

won't need to be built again, which should allow you to bypass this

specific problem. This worked for me, so I hope it works for you.

Why does it work? Well, the problem you observed occurs when running

the make-go target of the Makefile, which does the following (this is

from the Makefile.am file, which is used to produce the Makefile):

Toggle snippet (11 lines)make-go: $(MODULES) guix/config.scm $(dist_noinst_DATA)
        $(AM_V_at)echo "Compiling Scheme modules..." ;                  \
        unset GUILE_LOAD_COMPILED_PATH ;                                \
        XDG_CACHE_HOME=/nowhere                                         \
        host=$(host) srcdir="$(top_srcdir)"                             \
        $(top_builddir)/pre-inst-env                                    \
        $(GUILE) -L "$(top_builddir)" -L "$(top_srcdir)"                \
          --no-auto-compile                                             \
          -s "$(top_srcdir)"/build-aux/compile-all.scm $^

Here, we are running build-aux/compile-all.scm on all the modules in a
single invocation.  The script compile-all.scm compiles all the .scm
files it receives as arguments into .go files.  When it runs, it only
compiles a .go file if the .go file doesn't exist or the corresponding
.scm file is newer.  It seems this problem has something to do with
memoizing the gzip variable while compiling many different modules in
one run.  By only running compile-all.scm on the single module pack.scm,
it seems that we can avoid whatever condition is causing the problem to
occur.

As for what the actual issue is...  I don't know.  If somebody could
create a minimal reproduction of the issue, it would help.  The
information above gives us an idea of where the issue is probably
occurring, but it will require more work to narrow it down further.

-- 
Chris

Mark H Weaver wrote 7 years ago

bug#29774: Compilation error on git master: `gzip: unbound variable`

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 29774@debbugs.gnu.org)

Message-ID:87efj65qr6.fsf@netris.org

Hi,

I've run into this same problem, on my x86_64 GuixSD system. To help

others reproduce it, I've pushed a branch to Savannah, based on recent

core-updates. The branch is named 'reproduce-bug-29774'.

When I attempt to build this branch from a clean git checkout, within an

environment produced by "guix environment guix" from recent

core-updates, it consistently fails with this error. If I simply revert

the commit at the tip of that branch (an early draft of my "Detecting

duplicate field initializers" patch), then the problem does not occur.

I find it quite surprising that this apparently unrelated patch makes

any difference to this bug, but that seems to be the case.

Ludovic, are you able to reproduce this problem on your system? If

needed, I could also provide the precise derivation of the build

environment profile, but I suspect that "guix environment guix" produced

by any commit close to recent core-updates would work.

See below for the tail of my failed build log.

Mark

Toggle snippet (47 lines)  LOAD     guix/scripts/archive.scm
  LOAD     guix/scripts/import.scm
  LOAD     guix/scripts/package.scm
  LOAD     guix/scripts/gc.scm
  LOAD     guix/scripts/hash.scm
  LOAD     guix/scripts/pack.scm
Backtrace:
In ice-9/boot-9.scm:
    142:2 19 (dynamic-wind _ _ #<procedure 2701760 at ice-9/eval.scm:330:13 ()>)
    142:2 18 (dynamic-wind _ _ #<procedure 27013e0 at ice-9/eval.scm:330:13 ()>)
In ice-9/eval.scm:
    619:8 17 (_ #(#(#<directory (guix build compile) 21988c0> #<variable 252b550 value: 674> #<procedure 26fe3c0 at ice-9/eval.scm:339:13 (a b c)> 1 # …)))
    619:8 16 (_ #(#(#(#(#(#(#(#<directory (guix build compile) 21988c0> ("guix/scripts/pack.scm" "guix/scripts/pull.scm" "guix/scri…" …) …)) …) …) …) …) …))
In ice-9/boot-9.scm:
    152:2 15 (with-fluid* _ _ _)
  2788:17 14 (resolve-interface (guix scripts pack) #:select _ #:hide _ #:prefix _ #:renamer _ #:version _)
  2714:10 13 (_ (guix scripts pack) _ _ #:ensure _)
  2982:16 12 (try-module-autoload _ _)
   2312:4 11 (save-module-excursion #<procedure 60f7000 at ice-9/boot-9.scm:2983:17 ()>)
  3002:22 10 (_)
In unknown file:
           9 (primitive-load-path "guix/scripts/pack" #<procedure 69e5f60 at ice-9/boot-9.scm:2989:32 ()>)
In ice-9/eval.scm:
   626:19  8 (_ #<directory (guix scripts pack) 7891960>)
   173:39  7 (_ #<directory (guix scripts pack) 7891960>)
   202:51  6 (_ #<directory (guix scripts pack) 7891960>)
   202:35  5 (_ #<directory (guix scripts pack) 7891960>)
    155:9  4 (_ #<directory (guix scripts pack) 7891960>)
   202:35  3 (_ #<directory (guix scripts pack) 7891960>)
    159:9  2 (_ #<directory (guix scripts pack) 7891960>)
   223:20  1 (proc #<directory (guix scripts pack) 7891960>)
In unknown file:
           0 (%resolve-variable (7 . gzip) #<directory (guix scripts pack) 7891960>)

ERROR: In procedure %resolve-variable:
gzip: unbound variable

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
make[2]: *** [Makefile:5344: make-go] Error 1
make[2]: Leaving directory '/home/mhw/guix'
make[1]: *** [Makefile:4456: all-recursive] Error 1
make[1]: Leaving directory '/home/mhw/guix'
make: *** [Makefile:3103: all] Error 2

Ludovic Courtès wrote 6 years ago

control message for bug #29774

Recipients:(address . control@debbugs.gnu.org)

Message-ID:87k1njj5qf.fsf@gnu.org

severity 29774 important

Ludovic Courtès wrote 6 years ago

Re: bug#29774: Compilation error on git master: `gzip: unbound variable`

Recipients:(name . Mark H Weaver)(address . mhw@netris.org)(address . 29774-done@debbugs.gnu.org)

Message-ID:87va2gibdk.fsf@gnu.org

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

Toggle quote (13 lines)> I've run into this same problem, on my x86_64 GuixSD system.  To help
> others reproduce it, I've pushed a branch to Savannah, based on recent
> core-updates.  The branch is named 'reproduce-bug-29774'.
>
> When I attempt to build this branch from a clean git checkout, within an
> environment produced by "guix environment guix" from recent
> core-updates, it consistently fails with this error.  If I simply revert
> the commit at the tip of that branch (an early draft of my "Detecting
> duplicate field initializers" patch), then the problem does not occur.
>
> I find it quite surprising that this apparently unrelated patch makes
> any difference to this bug, but that seems to be the case.

[...]

Toggle quote (35 lines)>   LOAD     guix/scripts/package.scm
>   LOAD     guix/scripts/gc.scm
>   LOAD     guix/scripts/hash.scm
>   LOAD     guix/scripts/pack.scm
> Backtrace:
> In ice-9/boot-9.scm:
>     142:2 19 (dynamic-wind _ _ #<procedure 2701760 at ice-9/eval.scm:330:13 ()>)
>     142:2 18 (dynamic-wind _ _ #<procedure 27013e0 at ice-9/eval.scm:330:13 ()>)
> In ice-9/eval.scm:
>     619:8 17 (_ #(#(#<directory (guix build compile) 21988c0> #<variable 252b550 value: 674> #<procedure 26fe3c0 at ice-9/eval.scm:339:13 (a b c)> 1 # …)))
>     619:8 16 (_ #(#(#(#(#(#(#(#<directory (guix build compile) 21988c0> ("guix/scripts/pack.scm" "guix/scripts/pull.scm" "guix/scri…" …) …)) …) …) …) …) …))
> In ice-9/boot-9.scm:
>     152:2 15 (with-fluid* _ _ _)
>   2788:17 14 (resolve-interface (guix scripts pack) #:select _ #:hide _ #:prefix _ #:renamer _ #:version _)
>   2714:10 13 (_ (guix scripts pack) _ _ #:ensure _)
>   2982:16 12 (try-module-autoload _ _)
>    2312:4 11 (save-module-excursion #<procedure 60f7000 at ice-9/boot-9.scm:2983:17 ()>)
>   3002:22 10 (_)
> In unknown file:
>            9 (primitive-load-path "guix/scripts/pack" #<procedure 69e5f60 at ice-9/boot-9.scm:2989:32 ()>)
> In ice-9/eval.scm:
>    626:19  8 (_ #<directory (guix scripts pack) 7891960>)
>    173:39  7 (_ #<directory (guix scripts pack) 7891960>)
>    202:51  6 (_ #<directory (guix scripts pack) 7891960>)
>    202:35  5 (_ #<directory (guix scripts pack) 7891960>)
>     155:9  4 (_ #<directory (guix scripts pack) 7891960>)
>    202:35  3 (_ #<directory (guix scripts pack) 7891960>)
>     159:9  2 (_ #<directory (guix scripts pack) 7891960>)
>    223:20  1 (proc #<directory (guix scripts pack) 7891960>)
> In unknown file:
>            0 (%resolve-variable (7 . gzip) #<directory (guix scripts pack) 7891960>)
>
> ERROR: In procedure %resolve-variable:
> gzip: unbound variable

I was able to reproduce it on this ‘reproduce-bug-29774’ branch, and
also by just cherry-picking the detect-duplicate-field-initializer patch
on top of ‘master’.

As it turns out, build-aux/compile-all.scm was simply hiding the actual
error message, which was a duplicate field initializer in (gnu packages
haskell), and eventually threw that backtrace because (guix scripts
pack) is the module that indirectly triggered the loading of (gnu
packages haskell).  (Setting ‘%load-verbosely’ is what helped me find
out…)

Commit 1709b2e414195ae41a66d4fec37a25b1602629f7 lets those error
messages through, and commit 22a894bedd62181cdd382da3f0d49aea7fcd3a1a
implements duplicate field initializer detection in a way slightly
different from your original patch.

Thanks,
Ludo’.

Closed

Your comment

This issue is archived.

To comment on this conversation send an email to 29774@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 29774

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags

mumi command -t +confirmed -t +easy

Or, remove the moreinfo tag and set the help tag

mumi command -t -moreinfo -t +help

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date