In reply to @ss:someonex.net
connor (he/him): is there currently an open issue tracking this stdenv/compiler compatibility problem specifically?

RE: opencv in BSRT as well as tensorflow and jax

Is there a chance we misinterpret the "wrong glibc" errors, them using auto-patchelf-ed non-redist cudatoolkit

RE: opencv in BSRT as well as tensorflow and jax

Is there a chance we misinterpret the "wrong glibc" errors, them using auto-patchelf-ed non-redist cudatoolkit?

In reply to @ss:someonex.net
connor (he/him): is there currently an open issue tracking this stdenv/compiler compatibility problem specifically?

In reply to @mcwitt:matrix.org

Is there an issue with cudaPackages since the the gcc version bump to 12? I'd expect the following to work

let pkgs = import ./. { };
in pkgs.runCommandCC "test" { buildInputs = with pkgs.cudaPackages; [ cuda_nvcc cuda_cudart ]; } ''
  nvcc ${pkgs.writeText "test.cu" "int main() { return 0; }"} -o $out
''

but on master I see

error -- unsupported GNU version! gcc versions later than 11 are not supported!

(might be missing something because I'm not immediately finding workarounds that were necessary for other CUDA packages since gcc was bumped)

RE: -allow-unsupported=compiler

Ok, I tried building faiss with that flag on, getting some gcc errors: /nix/store/9pgq84sf921xh97gjj2wh7a7clrcrh4m-gcc-12.2.0/include/c++/12.2.0/bits/random.h(104): error: expected a declaration

So, the ugly and straightforward version could look like this:

{ config
, stdenv
, ...
, cudaSupport ? config.cudaSupport or false
, cudaPackages
}:


(if cudaSupport then cudaPackages.stdenv else stdenv).mkDerivation { ... }

So, the ugly and straightforward version could look like this:

{ config
, stdenv
, ...
, cudaSupport ? config.cudaSupport or false
, cudaPackages
}:


(if cudaSupport then cudaPackages.stdenv else stdenv).mkDerivation { ... }

In reply to @mcwitt:matrix.org
Just to close the loop, the fix in my case was to set cmakeFlags = [ "-DCMAKE_CUDA_HOST_COMPILER=${cudaPackages.cudatoolkit.cc}/bin/cc" ] (and eventually found many examples of this in nixpkgs). Thanks for pointing me in the right direction!

Three more things that popped into my head (sorry, I am actively consuming coffee):

1. When we do override the C/C++ compilers by setting the CC/CXX environment variables, that doesn't change binutils, so (in my case) I still see ar/ranlib/ld and friends from gcc12 being used. Is that a problem? I don't know if version bumps to those tools can cause as much damage as libraries compiled with different language standards.
2. If a package needs to link against libcuda.so specifically, what's the best way to make the linker aware of those stubs? I set LIBRARY_PATH and that seemed to do the trick: https://github.com/NixOS/nixpkgs/pull/218166/files#diff-ab3fb67b115c350953951c7c5aa868e8dd9694460710d2a99b845e7704ce0cf5R76
3. Is it better to set environment variables as env.BLAG = "blarg" (I saw a tree-wide change about using env because of "structuredAttrs") in the derivation or to export them in the shell, in something like preConfigure?