Don't reuse host's setup-exe-cache inside docker container

[mboes]

Reusing binaries, even statically linked binaries, from the host inside the docker container is dangerous. The reason is that on the host paths may be arbitrarily different, including that for the dynamic loader. For this reason, the setup-exe-cache/ folder should not be reused.

For example, on NixOS I get:

$ stack --install-ghc build    
base-orphans-0.4.4: copying precompiled package
base64-bytestring-1.0.0.1: configure
ansi-terminal-0.6.2.3: configure
byteable-0.1.1: configure
bytestring-trie-0.2.4.1: download
bytestring-trie-0.2.4.1: configure
/home/mboes/.stack/setup-exe-cache/setup-Simple-Cabal-1.22.4.0-x86_64-linux-ghc-7.10.2: singleBuild: runInteractiveProcess: exec: does not exist (No such file or directory)

However, if I first rm -rf ~/.stack/setup-exe-cache, then things work fine. The reason is that on NixOS the path to ld is /nix/store/hd6km3hscbgl2yw8nx7lr5z9s8h89p04-glibc-2.21/lib/ld-linux-x86-64.so.2 (on my particular system). Furthermore, the setup binary that is cached is in fact a dynamically linked executable: those libraries it depends on may or may not have the same version / path on the host than in the container.

[borsboom]

Related: #911

On Wed, Nov 18, 2015 at 6:49 AM Mathieu Boespflug [email protected]
wrote:

Reusing binaries, even statically linked binaries, from the host inside
the docker container is dangerous. The reason is that on the host paths may
be arbitrarily different, including that for the dynamic loader. For this
reason, the setup-exe-cache/ folder should not be reused.

For example, on NixOS I get:

$ stack --install-ghc build
base-orphans-0.4.4: copying precompiled package
base64-bytestring-1.0.0.1: configure
ansi-terminal-0.6.2.3: configure
byteable-0.1.1: configure
bytestring-trie-0.2.4.1: download
bytestring-trie-0.2.4.1: configure
/home/mboes/.stack/setup-exe-cache/setup-Simple-Cabal-1.22.4.0-x86_64-linux-ghc-7.10.2: singleBuild: runInteractiveProcess: exec: does not exist (No such file or directory)

However, if I first rm -rf ~/.stack/setup-exe-cache, then things work
fine. The reason is that on NixOS the path to ld is
/nix/store/hd6km3hscbgl2yw8nx7lr5z9s8h89p04-glibc-2.21/lib/ld-linux-x86-64.so.2
(on my particular system). Furthermore, the setup binary that is cached
is in fact a dynamically linked executable: those libraries it depends on
may or may not have the same version / path on the host than in the
container.

—
Reply to this email directly or view it on GitHub
#1367.