Remove ancient CUDA toolkits (and corresponding CuDNN versions):
- Not supported by upstream anymore.
- We do not use them in nixpkgs.
- We do not test or actively maintain them.
- Anything but ancient GPUs is supported by newer toolkits.
Starting with version 8, CuDNN consists of multiple libraries.
Libraries (except libcudnn.so) are dlopen()ed on demand.
Since the CuDNN library path itself was not added to the rpath of the
libraries, use of CuDNN often fails with the following error:
Could not load library libcudnn_cnn_train.so.8.
Error: libcudnn_ops_train.so.8: cannot open shared object file: No such file or directory
Please make sure libcudnn_cnn_train.so.8 is in your library path!
This change fixes this by adding $ORIGIN/ to the rpath of all CuDNN
libraries.
With the update to CuDNN 8.1, we do not get the "maximum file size
exceeded" error anymore when patchelf'ing libcudnn_cnn_infer.so. This
change removes the exception for that library.
By default, MAGMA builds against compute capability 3.0 (among other
capabilities). However, support for this capability was dropped in
CUDA 11. This change fixes CUDA 11 support by excluding 3.0.
While at it, this change also adds support for newer compute
capabilities that are not enabled by MAGMA by default (to support
older CUDA versions).
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
We can use use `stdenv.hostPlatform.isStatic` instead, and move the
logic per package. The least opionated benefit of this is that it makes
it much easier to replace packages with modified ones, as there is no
longer any issue of overlay order.
CC @FRidh @matthewbauer
