Architecture: x86_64 RAM: 4GB Filesystem: EXT4 Guile version: 2.0.11 Guile-Git (Guile module) was manually compiled and installed by me fromhttps://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 2017x86_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 onfreenode. 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 pagehttps://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 fromhttps://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 <email@example.com>, first searching for previous reports of this issue
I can reproduce this error when attempting to build Guix 0.14.0 fromsource, using system-provided and custom built dependencies. I cannotreproduce 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 trythe following: 1) Run a command like "make V=1". Because Guix uses GNU Automake, youcan get verbose output by adding "V=1" to the command ((automake)Automake Silent Rules). This will cause make to print the commands thatare being run. 2) Find the exact "compile-all.scm" invocation being used (it shouldappear right after the string "Compiling Scheme modules..." in the buildoutput). Copy it and run it manually from the root of the builddirectory (i.e., the directory containing the "configure" script), butinstead of passing it all the .scm files, only pass it the single fileguix/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, itwon't need to be built again, which should allow you to bypass thisspecific problem. This worked for me, so I hope it works for you. Why does it work? Well, the problem you observed occurs when runningthe make-go target of the Makefile, which does the following (this isfrom the Makefile.am file, which is used to produce the Makefile):
Here, we are running build-aux/compile-all.scm on all the modules in asingle invocation. The script compile-all.scm compiles all the .scmfiles it receives as arguments into .go files. When it runs, it onlycompiles 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 withmemoizing the gzip variable while compiling many different modules inone 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 tooccur. As for what the actual issue is... I don't know. If somebody couldcreate a minimal reproduction of the issue, it would help. Theinformation above gives us an idea of where the issue is probablyoccurring, but it will require more work to narrow it down further. -- Chris
Hi, I've run into this same problem, on my x86_64 GuixSD system. To helpothers reproduce it, I've pushed a branch to Savannah, based on recentcore-updates. The branch is named 'reproduce-bug-29774'. When I attempt to build this branch from a clean git checkout, within anenvironment produced by "guix environment guix" from recentcore-updates, it consistently fails with this error. If I simply revertthe commit at the tip of that branch (an early draft of my "Detectingduplicate field initializers" patch), then the problem does not occur. I find it quite surprising that this apparently unrelated patch makesany difference to this bug, but that seems to be the case. Ludovic, are you able to reproduce this problem on your system? Ifneeded, I could also provide the precise derivation of the buildenvironment profile, but I suspect that "guix environment guix" producedby any commit close to recent core-updates would work. See below for the tail of my failed build log. Mark
Re: bug#29774: Compilation error on git master: `gzip: unbound variable`
(name . Mark H Weaver)(address . firstname.lastname@example.org)(address . email@example.com)
Hi Mark, Mark H Weaver <firstname.lastname@example.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.
I was able to reproduce it on this ‘reproduce-bug-29774’ branch, andalso by just cherry-picking the detect-duplicate-field-initializer patchon top of ‘master’. As it turns out, build-aux/compile-all.scm was simply hiding the actualerror message, which was a duplicate field initializer in (gnu packageshaskell), and eventually threw that backtrace because (guix scriptspack) is the module that indirectly triggered the loading of (gnupackages haskell). (Setting ‘%load-verbosely’ is what helped me findout…) Commit 1709b2e414195ae41a66d4fec37a25b1602629f7 lets those errormessages through, and commit 22a894bedd62181cdd382da3f0d49aea7fcd3a1aimplements duplicate field initializer detection in a way slightlydifferent from your original patch. Thanks,Ludo’.