Ludovic Courtès <[email protected]> skribis: > In this case, adding ‘coreutils’ to the profile (on the ‘guix pack’ > command line) would give us wrapped binaries, and the problem is solved. > But in other cases, it’s not that simple. For instance, libmpi.so from > Open MPI tries to exec one its programs, using its absolute file name: > > $ unshare -m -U -r -f sh -c 'mount -t tmpfs none /gnu; > GUIX_EXECUTION_ENGINE=fakechroot /tmp/fakechroot-test/bin/IMB-MPI1' > -------------------------------------------------------------------------- > The singleton application was not able to find the executable "orted" in > your PATH or in the directory where Open MPI/OpenRTE was initially installed, > and therefore cannot continue. > > For reference, we tried the following command: > > /gnu/store/c7g9qalmbz4a94hwzk1v1cbq7n5m8plq-openmpi-4.1.4/bin/orted > > and got the error No such file or directory.
In the case of Open MPI as shown above, there’s actually an easy fix: telling Open MPI where to look for ‘orted’. Assuming you created a pack with: guix pack -RR openmpi intel-mpi-benchmarks bash-minimal -S /bin=bin You can run code extracted from the tarball like this: --8<---------------cut here---------------start------------->8--- export GUIX_EXECUTION_ENGINE=performance salloc -N2 ./bin/mpirun -np 2 --launch-agent ./bin/orted \ --map-by node -x GUIX_EXECUTION_ENGINE=performance -- \ ./bin/IMB-MPI1 PingPong --8<---------------cut here---------------end--------------->8--- The ‘--launch-agent’ trick allows us to work around the fact that exec’d code escapes the fakechroot environment. I’m closing this bug as “wontfix”. Ludo’.
