wrapBintoolsWith: support LINK.EXE-style args in purity checks

LLD supports Windows-style linker arguments, but these previously
triggered purity check false positives, because it saw that they
started with a '/' and assumed they were paths.

This tweaks the path detection to allow through certain values that
could be paths, but are much more likely to be LINK.EXE-style flags.
The risk of false negatives here is low — the only things we'd now
fail to catch would be attempts to link with libraries in the root
directory, which doesn't happen in practice.

We also teach the wrapper how to apply its purity checks to library
paths specified with the /LIBPATH: option.

Tested that paths we expect to be rejected (like /lib/libfoo.so) still
are.

1 files changed, 6 insertions, 1 deletions

diff --git a/pkgs/build-support/wrapper-common/utils.bash b/pkgs/build-support/wrapper-common/utils.bash
index 44b44818c8ed9..2faf96df15b40 100644
--- a/pkgs/build-support/wrapper-common/utils.bash
+++ b/pkgs/build-support/wrapper-common/utils.bash
@@ -84,12 +84,17 @@ mangleVarSingle() {
     done
 }
 
-skip () {
+skip() {
     if (( "${NIX_DEBUG:-0}" >= 1 )); then
         echo "skipping impure path $1" >&2
     fi
 }
 
+reject() {
+    echo "impure path \`$1' used in link" >&2
+    exit 1
+}
+
 
 # Checks whether a path is impure.  E.g., `/lib/foo.so' is impure, but
 # `/nix/store/.../lib/foo.so' isn't.