Ok, I have just tried to build the binary tarball on a VM where I reproduced all the paths I want (basically, instead of /gnu I want /shared/shape_tier3/common/local/guix) and which has c++11 compliant gcc -- that also failed. I pulled today's git and ran guix-daemon --no-substitutes. The error seems to be "unable to fork: Operation not permitted". I am running guix-daemon as myself and I have all permissions to the /.../local/guix): GUIX_PACKAGE_PATH= \ ./pre-inst-env "/usr/bin/guile" \ "./build-aux/make-binary-tarball.scm" "x86_64-linux" "guix-binary.x86_64-linux.tar.xz" ......... | recursively deleting path `/shared/shape_tier3/common/local/guix/store/m38laca1idmvx8m03dl6b5qmn8xhv9c3-guile-bootstrap-2.0.drv.chroot' | lock released on `/shared/shape_tier3/common/local/guix/store/pgs6vqy03wg2m5mn2ahvi4sarx89vnls-guile-bootstrap-2.0.lock' | building of `/shared/shape_tier3/common/local/guix/store/m38laca1idmvx8m03dl6b5qmn8xhv9c3-guile-bootstrap-2.0.drv': goal destroyed Backtrace: In ice-9/boot-9.scm: 157: 11 [catch #t # ...] In unknown file: ?: 10 [apply-smob/1 #] In ice-9/boot-9.scm: 63: 9 [call-with-prompt prompt0 ...] In ice-9/eval.scm: 432: 8 [eval # #] In ice-9/boot-9.scm: 2401: 7 [save-module-excursion #] 4052: 6 [#] In unknown file: ?: 5 [load-compiled/vm "/home/alex/.cache/guile/ccache/2.0-LE-8-2.0/home/alex/src/guix/build-aux/make-binary-tarball.scm.go"] In build-aux/make-binary-tarball.scm: 38: 4 [#] In guix/store.scm: 986: 3 [run-with-store # ...] In build-aux/make-binary-tarball.scm: 41: 2 [# #] In guix/store.scm: 933: 1 [# #] 624: 0 [build-things # #] guix/store.scm:624:0: In procedure build-things: guix/store.scm:624:0: Throw to key `srfi-34' with args `(#)'. Makefile:4331: recipe for target 'guix-binary.x86_64-linux.tar.xz' failed make: [guix-binary.x86_64-linux.tar.xz] Error 1 (ignored) Thanks, Alex On Fri, May 22, 2015 at 8:45 AM, Ludovic Courtès wrote: > Alexander Vorobiev skribis: > > > Doesn't binary distribution have hardcoded /gnu/* paths? > > Yes it does. > > > I can't use those unfortunately. We have a standard configuration of > > RHEL 6.5 installed on hundreds of servers and any modifications of the > > root directory (and all other "standard" directories) layout are out > > of question. > > OK. Note that using a store other than /gnu/store prevents you from > using substitutes from hydra.gnu.org (just mentioning it if that is of > interest to you.) > > > Would it be too hard to add an environment variable(s) pointing to a > > Guix's store and cache directories so that the binary build of the > > daemon doesn't depend on the hardcoded values? Thanks, Alex > > There are two issues here: > > 1. File names hard-coded in the RUNPATH and other places of the > ‘guix-daemon’ binary of the tarball. > > 2. The store directory that ‘guix-daemon’ targets. > > #2 can actually be changed at run-time via the (purposefully > undocumented) ‘NIX_STORE_DIR’ environment variable (see ‘test-env.in’ in > the source tree.) > > #1 means that if you want to run the ‘guix-daemon’ binary from the > binary tarball, you’ll have to somehow satisfy its requirements. You > might be able to unpack the tarball in an arbitrary directory, and then > define ‘LD_LIBRARY_PATH’ so that ‘guix-daemon’ finds all the .so files > that it needs and are provided by the binary tarball (libstdc++.so, > libgcrypt.so, libsqlite3.so, libc.so, etc.) > > Once ‘guix-daemon’ is running, you could run ‘guix environment guix’, > and from there you could build Guix from source. > > But that is really hacky, and perhaps not particularly easier than > building a newer GCC on your machine. > > Alternately, you could build a suitable binary tarball on another > machine: just install and configure Guix with the options that you need, > and run ‘make guix-binary.x86_64-linux.tar.xz’. > > WDYT? > > Ludo’. >