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
The libtorch CMake files are in the `dev` output and used relative
paths to locate the shared libraries. This fails, because the
libraries are in the `out` output. This change patches the CMake files
to use library paths from `out`.
See #102146.
- Make passthru.tests an attrset.
- Remove CMake VERBOSE option.
- Remove spurious `cat CMakeLists.txt`.
- Run the test as well.
- Actually test some functionality.
The MKL pkg-config files often change and are then incorrect for our
paths. pkg-config validation finds some issues, but not incorrect
paths. So, add a small test program to test whether the generated
pkg-config files can actually be used to build a functioning
binary. Hopefully this catches future regressions.
Daniël de Kok
Bernardo Meurer
R. RyanTM
Ben Siraphob
volth
Markus Kowalewski
zowoq
Jonathan Ringer
Rémy Grünblatt
Mike Sperber
github-actions[bot]
John Ericson
Thomas Tuegel
Pavol Rusnak
Sandro
freezeboy
Timo Kaufmann
Evils
Frederik Rietdijk