This is a hot-fix to un-break cuda-enabled packages (like tensorflow,
jaxlib, faiss, opencv, ...) after the gcc11->gcc12 bump. We should
probably build the whole downstream packages with a compatible stdenv
(such as gcc11Stdenv for cudaPackages_11), but just pointing nvcc at the
right compiler seems to do the trick
We already used this hack for non-redist cudatoolkit. Now we use it more
consistently.
This commit also re-links cuda packages against libstdc++ from the same
"compatible" gcc, rather than the current stdenv. We didn't test if this
is necessary -> need to revise in further PRs.
NOTE: long-term we should make it possible to override -ccbin and use
e.g. clang
As cudatoolkit is currently written, 11.8 introduces a broken symlink in `include` (also named `include`) and in `lib` (named `lib64`).
This trips up some consumers, like `tensorflow-gpu`.
python27 was recently marked as insecure, breaking cudaPackages.cudatoolkit. This commit has been successfully tested against the earliest supported, 10.0, and the latest supported, 11.8, with the assumption that intermediate versions ought to work as well.
There are many different versions of the `cudatoolkit` and related
cuda packages, and it can be tricky to ensure they remain compatible.
- `cudaPackages` is now a package set with `cudatoolkit`, `cudnn`, `cutensor`, `nccl`, as well as `cudatoolkit` split into smaller packages ("redist");
- expressions should now use `cudaPackages` as parameter instead of the individual cuda packages;
- `makeScope` is now used, so it is possible to use `.overrideScope'` to set e.g. a different `cudnn` version;
- `release-cuda.nix` is introduced to easily evaluate cuda packages using hydra.
This has the benefit of being able to override all the inputs to the
build where you were previously only able to override the entire package
set (if at all).
