ld-wrapper.sh complaints about impure path when /nix is a symlink

[alexvorobiev]

Issue description

Due to space constraints I have /nix symlinked to another partition and use NIX_IGNORE_SYMLINK_STORE=1. It worked well until I tried to compile something which gave me "impure path" error. For instance, here is the error I got when I tried to install an R package which uses c++ code:

$ nix-env -iA nixpkgs.rPackages.dplyr
...
/nix/store/xxy7xrcg64c5xvx486f704q15kpp3cxh-gfortran-wrapper-5.3.0/bin/g++ -shared -L/nix/store/c3sv2mmaff38zxwgwk81mr4jg46n6m21-R-3.2.3/lib/R/lib -o Rcpp.so Date.o Module.o Rcpp_init.o api.o attributes.o barrier.o -L/nix/store/c3sv2mmaff38zxwgwk81mr4jg46n6m21-R-3.2.3/lib/R/lib -lR
impure path `/opt/revr/nix/store/21dzw5ab4prm9z2var85l4aiq32wfwfc-gfortran-5.3.0/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/liblto_plugin.so' used in link
collect2: error: ld returned 1 exit status

/nix is a symlink:

$ ls -l /nix
lrwxrwxrwx 1 root root 13 Feb  9 22:15 /nix -> /opt/revr/nix/

The error seems to be thrown here: ld-wrapper.sh#L31 so it looks like badPath doesn't recognize the path properly.

Steps to reproduce

1. Make /nix a symlink and use NIX_IGNORE_SYMLINK_STORE=1
2. Run nix-env -iA nixpkgs.rPackages.dplyr

   Technical details

   • System: $ lsb_release -a LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch Distributor ID: RedHatEnterpriseServer Description: Red Hat Enterprise Linux Server release 6.7 (Santiago) Release: 6.7 Codename: Santiago
   • Nix version: $ nix-env --version nix-env (Nix) 1.11.2
   • Nixpkgs version: $ nix-instantiate --eval '' -A lib.nixpkgsVersion "16.09pre83147.df89584"

[danbst]

have you tried using bind mount instead of link? In my setup I mount /nix/store as separate partition and don't have (such) problems

[alexvorobiev]

@danbst Changing symlink to the bind mount fixed the problem for me, thanks! But still, since the symlinks are officially supported and the NIX_IGNORE_SYMLINK_STORE is documented, I think it should count as a bug...

[knedlsepp]

It seems that exporting export NIX_STORE=$(realpath /nix/store) could help here. It however starts a local build instead of fetching from the binary cache...

[RonnyPfannschmidt]

@knedlsepp not surprising, the store path is part of the cache hash keys, changing it makes everything "uncached"

[knedlsepp]

@RonnyPfannschmidt That makes a lot of sense.