Hi Guix! With the recent call for testing on core-updates-frozen I thought I'd test my router configuration on the RockPro64 and I saw that building the stripped static guile for initrd didn't build. I found a fix but I'm not 100% sure it's correct, so beware, here's my debugging session! %guile-static-stripped fails to build as such: --8<---------------cut here---------------start------------->8--- $ ./pre-inst-env guix build -e '(@ (gnu packages make-bootstrap) %guile-static-stripped)' ... Backtrace: 1 (primitive-load "/gnu/store/gz31w23fjaipnm9c9hzw6p8s619?") In guix/build/utils.scm: 761:6 0 (invoke "/gnu/store/9rwp8z98xdllih5rzf2ncq25xhnkgcvq-g?" ?) guix/build/utils.scm:761:6: In procedure invoke: ERROR: 1. &invoke-error: program: "/gnu/store/9rwp8z98xdllih5rzf2ncq25xhnkgcvq-guile-static-stripped-3.0.7/bin/guile" arguments: ("--version") exit-status: 127 term-signal: #f stop-signal: #f --8<---------------cut here---------------end--------------->8--- The stripped guile crashes, and if we check it, it's actually not a static binary! So when stripping out store references we break it of course: --8<---------------cut here---------------start------------->8--- $ file /gnu/store/9rwp8z98xdllih5rzf2ncq25xhnkgcvq-guile-static-stripped-3.0.7/bin/guile /gnu/store/9rwp8z98xdllih5rzf2ncq25xhnkgcvq-guile-static-stripped-3.0.7/bin/guile: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.33/lib/ld-linux-aarch64.so.1, for GNU/Linux 2.6.32, stripped ^^^^^^^^ Oups :-) --8<---------------cut here---------------end--------------->8--- The root of the issue seems to be that the make-guile-static procedure isn't actually producing a static binary on aarch64. Digging into it more, we do pass the -all-static flag to libtool, but the gcc command doesn't actually do any static linking: --8<---------------cut here---------------start------------->8--- /tmp/guix-build-guile-static-3.0.7.drv-0/guile-3.0.7$ make V=1 ... ../libtool --tag=CC --mode=link gcc -std=gnu11 -pthread -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing -fwrapv -fvisibility=hidden -g -O2 -all-static -pthread -ldl -o guile guile-guile.o libguile-3.0.la -ldl -lcrypt -lm libtool: link: gcc -std=gnu11 -pthread -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing -fwrapv -fvisibility=hidden -g -O2 -pthread -o guile guile-guile.o ./.libs/libguile-3.0.a -L/gnu/store/3539zsmc939g1r9g3r02bpy0m1b9v9c8-libgc-8.0.4/lib -L/gnu/store/sn95w7yk9qwxhw74l590606y53pf5mkf-libffi-3.3/lib /gnu/store/3539zsmc939g1r9g3r02bpy0m1b9v9c8-libgc-8.0.4/lib/libgc.a -lpthread /gnu/store/sn95w7yk9qwxhw74l590606y53pf5mkf-libffi-3.3/lib/libffi.a -lunistring -ldl -lcrypt -lm -pthread --8<---------------cut here---------------end--------------->8--- And if we try and do a static link anyway, it doens't work because of missing references related to atomic ops. My guess is that libtool tried to statically link, and fell back to dynamic linking when that didn't work, I'm not so sure. --8<---------------cut here---------------start------------->8--- /tmp/guix-build-guile-static-3.0.7.drv-0/guile-3.0.7/libguile$ gcc -std=gnu11 -pthread -Wall -Wmissing-prototypes -Wpointer-arith -fno-strict-aliasing -fwrapv -fvisibility=hidden -g -O2 -pthread -o guile guile-guile.o ./.libs/libguile-3.0.a -L/gnu/store/3539zsmc939g1 r9g3r02bpy0m1b9v9c8-libgc-8.0.4/lib -L/gnu/store/sn95w7yk9qwxhw74l590606y53pf5mkf-libffi-3.3/lib /gnu/store/3539zsmc939g1r9g3r02bpy0m1b9v9c8-libgc-8.0.4/lib/libgc.a -lpthread /gnu/store/sn95w7yk9qwxhw74l590606y53pf5mkf-libffi-3.3/lib/libffi.a -lunistring -ldl -lcrypt -lm -p thread -static ld: ./.libs/libguile-3.0.a(libguile_3.0_la-dynl.o): in function `scm_dlopen': /tmp/guix-build-guile-static-3.0.7.drv-0/guile-3.0.7/libguile/dynl.c:78: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ld: ./.libs/libguile-3.0.a(libguile_3.0_la-posix.o): in function `scm_tmpnam': /tmp/guix-build-guile-static-3.0.7.drv-0/guile-3.0.7/libguile/posix.c:1611: warning: the use of `tmpnam' is dangerous, better use `mkstemp' ld: /gnu/store/b05hb686wamq78d5jzpisns9xdx6nkp2-glibc-2.33-static/lib/libc.a(abort.o): in function `abort': (.text.unlikely+0x34): undefined reference to `__aarch64_cas4_acq' ld: (.text.unlikely+0xa0): undefined reference to `__aarch64_swp4_rel' ld: (.text.unlikely+0xe4): undefined reference to `__aarch64_cas4_acq' ld: /gnu/store/b05hb686wamq78d5jzpisns9xdx6nkp2-glibc-2.33-static/lib/libpthread.a(pthread_create.o):(.text+0x5c): undefined reference to `__aarch64_cas4_acq' ld: /gnu/store/b05hb686wamq78d5jzpisns9xdx6nkp2-glibc-2.33-static/lib/libpthread.a(pthread_create.o):(.text+0x1fc): undefined reference to `__aarch64_cas4_acq' ld: /gnu/store/b05hb686wamq78d5jzpisns9xdx6nkp2-glibc-2.33-static/lib/libpthread.a(pthread_create.o):(.text+0x29c): undefined reference to `__aarch64_cas4_acq' ... --8<---------------cut here---------------end--------------->8--- Doing more digging, I found a reference to a similar issue here: https://bugzilla.redhat.com/show_bug.cgi?id=1830472#c1, this looks related to the -moutline-atomics option that's enabled by default with GCC 10. But we're building guile with GCC 7 so it was a bit confusing. However, glibc here is actually built with the default GCC 10, and if we change that then it works! --8<---------------cut here---------------start------------->8--- --- a/gnu/packages/make-bootstrap.scm +++ b/gnu/packages/make-bootstrap.scm @@ -85,6 +85,9 @@ (define glibc-for-bootstrap `(cons* "--disable-nscd" "--disable-build-nscd" "--enable-static-nss" ,flags)))) + (native-inputs + `(("gcc" ,gcc-7) + ,@(package-native-inputs base))) ;; Remove the 'debug' output to allow bit-reproducible builds (when the ;; 'debug' output is used, ELF files end up with a .gnu_debuglink, which --8<---------------cut here---------------end--------------->8--- I'm not 100% sure what's going on, there seems to be an incompatiblity between GCC 7 and 10, but I don't know if this is a bug or if it's working as intended. I have a feeling statically linking the libc with different compiler version might just not be supported, but it works in practise a lot of the time. Does this make sense? Do you think the following patch would be the right way to fix this? Thanks! Pierre