Thanks for the explanation. I didn’t make the connection that buildInputs is an attribute itself as it is an attribute of stdenv instead of the function describing the derivation directly. Or at least I think that’s where my confusion comes from.
I tripped over some stuff back then when I found out that which is not part of the sandbox.
That’s what buildInputs are for. Add which to buildInputs and it’s available inside the sandbox. The stdenv takes care of putting its binaries into $PATH and making its libraries discoverable.
In the case of which, you’d probably need it in order to execute its binary during the build process though, so nativeBuildInputs is more appropriate but that only truly matters for cross-compilation.
Small correction, it wasn’t which, but rather env, I had those mixed up. The “issue” is described here: github.com/NixOS/nixpkgs/issues/6227 What created more problems was that patchShebangs wouldn’t work here because it appeared in a configure script that was created and run during the actual build process (I think the build process is horrible, but here it is in case you’re inclined: github.com/BSI-Bund/TaSK/tree/master/tlstesttool the stuff in the 3rdparty directory gets downloaded, configured and linked against in the main program’s build phase so you have no opportunity to actually follow the solution in that issue, similar to what is described here github.com/NixOS/nixpkgs/issues/6227#issuecomment…. I got it to work in the end and like to tell myself that it’s elegant but the project’s build process is just bad in my opinion.
pastebin.com/0GwLk1wP if you want to see an example of my level of nix-fu. I have programming basics but the nix language can be confusing sometimes. I’d say I have a basic understanding of things but as said before the more intricate stuff still escapes me.