Hello! The “fakechroot” engine fails when applied to ‘bash’:
--8<---------------cut here---------------start------------->8--- $ guix pack -RR bash -S /bin=bin /gnu/store/mnbmklbvd1pk7yby0k8h26msk6z11m1m-bash-tarball-pack.tar.gz $ (cd /tmp/pack; tar xf /gnu/store/mnbmklbvd1pk7yby0k8h26msk6z11m1m-bash-tarball-pack.tar.gz) $ unshare -mrf sh -c 'mount -t tmpfs -o ro none /gnu/store; GUIX_EXECUTION_ENGINE=fakechroot /tmp/pack/bin/bash --version' /tmp/pack/gnu/store/d99ykvj3axzzidygsmdmzxah4lvxd6hw-bash-5.1.8/bin//bash: out of memory to store relocation results for /tmp/pack/bin/bash --8<---------------cut here---------------end--------------->8--- The message comes from ld.so. My guess is that the problem comes from Bash’s terrible ‘malloc’ replacement: --8<---------------cut here---------------start------------->8--- $ objdump -T /gnu/store/d99ykvj3axzzidygsmdmzxah4lvxd6hw-bash-5.1.8/bin/bash | grep malloc 00000000004ae6f0 g DF .text 000000000000003b Base malloc_usable_size 00000000004ae850 g DF .text 0000000000000009 Base malloc 0000000000484e70 g DF .text 000000000000005b Base xmalloc 00000000004ee020 g DO .bss 0000000000000004 Base malloc_trace_at_exit 00000000004e8c24 g DO .data 0000000000000004 Base malloc_mmap_threshold 0000000000484f70 g DF .text 00000000000000dd Base sh_xmalloc 00000000004f7a04 g DO .bss 0000000000000004 Base malloc_trace 00000000004f7a08 g DO .bss 0000000000000004 Base malloc_flags 00000000004ae730 g DF .text 0000000000000005 Base sh_malloc 00000000004f7a00 g DO .bss 0000000000000004 Base malloc_register 00000000004ae660 g DF .text 000000000000000c Base _malloc_unblock_signals 00000000004ae630 g DF .text 000000000000002e Base _malloc_block_signals --8<---------------cut here---------------end--------------->8--- [Time passes…] I confirmed this hypothesis by running: guix pack -RR -S /bin=bin -m manifest.scm on this manifest: --8<---------------cut here---------------start------------->8--- (use-modules (guix) (guix utils) (guix profiles) (gnu packages bash)) (define bash-sans-malloc (package/inherit bash (name "bash-sans-malloc") (arguments (substitute-keyword-arguments (package-arguments bash) ((#:configure-flags flags ''()) `(cons "--without-bash-malloc" ,flags)))))) (packages->manifest (list bash-sans-malloc)) --8<---------------cut here---------------end--------------->8--- Works just fine: --8<---------------cut here---------------start------------->8--- $ unshare -mrf sh -c 'mount -t tmpfs -o ro none /gnu/store; GUIX_EXECUTION_ENGINE=fakechroot /tmp/pack/bin/bash --version' GNU bash, version 5.1.8(1)-release (x86_64-unknown-linux-gnu) Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. --8<---------------cut here---------------end--------------->8--- So in the end, it’s a bug report that’s kinda closed already. Perhaps we should build Bash ‘--without-bash-malloc’ unconditionally in ‘core-updates’? The ‘INSTALL’ file reads: --8<---------------cut here---------------start------------->8--- '--with-bash-malloc' Use the Bash version of 'malloc' in the directory 'lib/malloc'. This is not the same 'malloc' that appears in GNU libc, but an older version originally derived from the 4.2 BSD 'malloc'. This 'malloc' is very fast, but wastes some space on each allocation. This option is enabled by default. The 'NOTES' file contains a list of systems for which this should be turned off, and 'configure' disables this option automatically for a number of systems. --8<---------------cut here---------------end--------------->8--- There might be other options if we want to keep it, such as changing the ELF visibility of those symbols, but I wonder if it’s worth the effort. Thoughts? Ludo’.