Efraim noticed core-updates breakage on package libgpg-error. TL;DR: ld-wrapper package embeds guile-2.2 interpreter to interpret ld.go bytecode built by guile-2.0. I have no idea how to fix it but still decided to share my findings so far. Longer story: The sympthon is broken ld: $ ./pre-inst-env guix build libgpg-error ... checking whether the C compiler works... no configure: error: in `/tmp/guix-build-libgpg-error-1.26.drv-0/libgpg-error-1.26': configure: error: C compiler cannot create executables See `config.log' for more details Namely minimal linking (from config.log) fails as: configure:3724: checking whether the C compiler works configure:3746: gcc conftest.c >&5 Backtrace: 5 (apply-smob/1 #) In ice-9/boot-9.scm: 710:2 4 (call-with-prompt ("prompt") # ?) In ice-9/eval.scm: 619:8 3 (_ #(#(#))) In ice-9/command-line.scm: 181:18 2 (_ #) In unknown file: 1 (eval (load-compiled "/gnu/store/qv0w20gdi57ybganx82?") #) 0 (load-compiled/vm "/gnu/store/qv0w20gdi57ybganx82w8ymk1?") ERROR: In procedure load-compiled/vm: ERROR: In procedure load-thunk-from-memory: No such file or directory collect2: error: ld returned 1 exit status configure:3750: $? = 1 configure:3788: result: no configure: failed program was: | /* confdefs.h */ | int | main () | { | return 0; | } configure:3793: error: in `/tmp/guix-build-libgpg-error-1.26.drv-0/libgpg-error-1.26': configure:3795: error: C compiler cannot create executables See `config.log' for more details That's right: it's the guile's backtrace from gcc invocation. /tmp/guix-build-libgpg-error-1.26.drv-0/libgpg-error-1.26 $ ld Backtrace: 5 (apply-smob/1 #) In ice-9/boot-9.scm: 710:2 4 (call-with-prompt ("prompt") # …) In ice-9/eval.scm: 619:8 3 (_ #(#(#))) In ice-9/command-line.scm: 181:18 2 (_ #) In unknown file: 1 (eval (load-compiled "/gnu/store/qv0w20gdi57ybganx82…") #) 0 (load-compiled/vm "/gnu/store/qv0w20gdi57ybganx82w8ymk1…") ERROR: In procedure load-compiled/vm: ERROR: In procedure load-thunk-from-memory: Backtrace tries to tell us that guile-2.2 cannot load ld.go file. Snippet from `which ld`: """ exec /gnu/store/kri8a2dy6dy0cdg0z41djn0pnn08515z-guile-2.2.0/bin/guile -c "(load-compiled \"/gnu/store/qv0w20gdi57ybganx82w8ymk1cwv7n2c-ld-wrapper-0/bin/ld.go\") (apply $main (cdr (command-line)))" "$@" """ File confirms bytecode is from incompatible 2.0 version: $ file /gnu/store/qv0w20gdi57ybganx82w8ymk1cwv7n2c-ld-wrapper-0/bin/ld.go /gnu/store/qv0w20gdi57ybganx82w8ymk1cwv7n2c-ld-wrapper-0/bin/ld.go: Guile Object, little endian, 64bit, bytecode v2.0 I think the problem comes from 'gnu/packages/base.scm:make-ld-wrapper' function which uses host's guile to compile ld.go, not bootstrapped guile: http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/base.scm#n458 (define* (make-ld-wrapper name #:key (target (const #f)) binutils (guile (canonical-package guile-2.0)) (bash (canonical-package bash)) (guile-for-build guile)) ... (arguments (let ((target (target (%current-system)))) `(#:guile ,guile-for-build #:modules ((guix build utils)) #:builder (begin ... (chmod ld #o555) (compile-file ld #:output-file go)))))) Which guile is being used here for compile-file? 'build-for-build' or current host's guile? Looks like the requirement here is that both mush be of the same version. If it really is a requirement to run guile-2.2 perhaps adding early assertion would be nicer? I don't know how to add it either :) Thanks! -- Sergei