This appears to be a known problem. Nix-build barfs but nix-shell works (manually) on the same derivation.
nix-build -I/home/brcamp -E ‘with import {}; callPackage ./default.nix {}’ -vvvv
fails.
Is there a work around?
What is your /home/brcamp/default.nix look like, what do you actually import (I doubt you import {}), what is in your ./default.nix and what is the working nix-shell invocation?
You can use markdown code fences in this forum and wrap your code in `:
This is text with `inline code`, while the next paragraph is codeblock:
```nix
{}
```
A fair point.
My invocation:
nix-build -I/home/brcamp -E 'with import <nixpkgs> {}; callPackage ./default.nix {}'
The default.nix
{ stdenvNoCC, fetchFromGitHub, cmake, clang, llvm, python3, doxygen, openssl, glibc, bash
, BUILD_TYPE ? "RelWithDebInfo"
}:
stdenvNoCC.mkDerivation {
name = "openenclave-sdk";
version = "0.12.0";
nativeBuildInputs = [ cmake llvm clang python3 doxygen bash ];
# Only one actual import to the package. Everything else is a build tool
buildInputs = [ openssl ];
src = fetchFromGitHub {
owner = "openenclave";
repo = "openenclave";
rev = "v0.12.0";
sha256 = "1kxwvdy114mcgzs4bap1vfsrwv1x093ds6pgbxwz0j2wgzyiyxli";
fetchSubmodules = true;
};
CC = "clang";
CXX = "clang++";
LD = "ld.lld";
CFLAGS="-Wno-unused-command-line-argument";
CXXFLAGS="-Wno-unused-command-line-argument";
NIX_ENFORCE_PURITY=0;
doCheck = false;
dontFixup = true;
dontStrip = true;
dontPatchELF = true;
builder = ./build.sh;
configureFlags = "-DCMAKE_BUILD_TYPE="+BUILD_TYPE;
enableParallelBuild = false;
configurePhase = ''
chmod -R a+rw $src
mkdir -p $out
cd $out
cmake -G "Unix Makefiles" $src $configureFlags
'';
# buildPhase = ''
# make VERBOSE=1
# '';
meta = with stdenvNoCC.lib; {
description = "OpenEnclave SDK.";
license = licenses.mit;
maintainers = with maintainers; [ yakman2020 ];
platforms = [ "x86_64-linux" ];
};
}
And the build.sh
#!/bin/bash
source $stdenv/setup
genericBuild
The error I’m getting today (it varies):
/nix/store/k8p54jg8ipvnfz435mayf5bnqhw4qqap-bash-4.4-p23/bin/bash: /nix/store/myjxqm5qbx9gsq6spvcy73hac5rwj89w-source/tests/crypto_crls_cert_chains/data/make-test-certs: /usr/bin/env: bad interpreter: No such file or directory
make[2]: *** [tests/crypto_crls_cert_chains/data/CMakeFiles/crypto_crls_cert_chains_test_data.dir/build.make:87: tests/crypto_crls_cert_chains/data/root.cert.pem] Error 126
make[1]: *** [CMakeFiles/Makefile2:9416: tests/crypto_crls_cert_chains/data/CMakeFiles/crypto_crls_cert_chains_test_data.dir/all] Error 2
make: *** [Makefile:182: all] Error 2
builder for '/nix/store/acp350hn6sqkxh2qgww1d1zrv6b61r75-openenclave-sdk.drv' failed with exit code 2
error: build of '/nix/store/acp350hn6sqkxh2qgww1d1zrv6b61r75-openenclave-sdk.drv' failed
Thank you for your time.
BTW, I tried adding env to nativeBuildInputs, but that is a problem because env is an anonymous function in nix.
There is no /usr/bin/env in the build sandbox. It is only added to NixOS for convenience but since builds are sandboxed, they cannot see it.
And even if you added a package that contains /bin/env path, it would not help, as the shebang expects it to be under /usr but the package would have it installed as /nix/store/7fdm1ij6f7xwjmhpici1bh3xh08n0sp7-coreutils-8.31/bin/env. When you add a package to nativeBuildInputs, it will not install it under /usr, it will just add its /bin directory to PATH. And either way, coreutils package, which contains env, should be on PATH by default.
What we usually do to fix it is run patchShebangs shell function on the files that need to fix the shebang. So you would do something like:
postPatch = ''
patchShebangs tests
'';
You also need to make sure that whatever is in the shebang after env is on PATH. So if there is #!/usr/bin/env python3, add python3 to nativeBuildInputs.
patchShebangs doesn’t repatch when it sees a #!/nix/store shebang. So if the expression changes, the path for the bash changes, and the shabang is not updated, so not found.
When I deleted the shebangs from the files, then nix-build’ed it worked.
Looks like a bug in patchShebang. It should repatch even if there is a #!/nix/store.
I would think it is intentional that it does not patch already patched files. We are running patchShebangs on the output tree during fixupPhase automatically so if it replaced store paths too, it might undo replacements done in previous steps. For example, we are patching fwupd to use a different version of Python than the one on PATH; with your proposal, the change would be overwritten.
Also, it is not typically an issue since projects themselves do not hard-code shebangs to point to store paths and, after you finish with preparations in nix-shell, you would be pointing src to a clean source tree anyway, so that nix-build is not affected by any impure build artefacts.