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

[Chris Marusich]

<address@hidden> writes:

>> 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):

--8<---------------cut here---------------start------------->8---
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 $^
--8<---------------cut here---------------end--------------->8---

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

signature.asc
Description: PGP signature