This shadows the regular fixDarwinDylibNames function, which is a
nativeBuildInput, and prevents it from converting some relative paths to
absolute. According to the comment this can be removed as of 5.7.2.
This is needed to build the CUDNN samples, so we should make sure it
winds up in $out/lib. The library is too big to support patchelf, so
we need to skip it. Most programs will still get the opengl path
because it also links to other libraries.
Other changes:
- Move gfortran and cmake to nativeBuildInputs.
- Magma now (only) generates dynamic libraries by default.
- Use ninja for faster builds.
libflame is a protable library for dense matrix computations,
providing a complete LAPACK implementation. The AMD fork of libflame
is optimized for AMD CPUs.
The PETSc library's config/install.py script checks whether
/usr/bin/install_name_tool is an existing file:
https://gitlab.com/petsc/petsc/-/blob/master/config/install.py#L368
Therefore, it is not enough to replace it with something that we expect
to be on the PATH, as this will cause the linked if statement to be
silently skipped. The consequence is that applications linked against
this version of petsc will fail at runtime on MacOS with a dynamic
loading error.
Instead, we should replace install_name_tool with the absolute path of a
binary we know will be present at build time.
Note that this should be fixed upstream as well, but this is sufficient
to fix the runtime error.
We compile specifically for Zen:
- Zen/Zen2 are not included in the x86_64 or amd64 configurations.
- Including them breaks AMD BLIS in other places, since some functions
have Zen-specific definitions that fail on other platforms.
Non-Zen CI runners will succeed when they are Haswell or later, since
a Haswell kernel is compiled as a dependency.
The Intel MKL pkg-config files did not work, because they expect that
the MKLROOT environment variable is set. This change replaces
occurences by the actual path of MKL in the Nix store.
Since the pkg-config files seem to break quite frequently after
upgrades, add a post-install check to validate the pkg-config files.
This is a better name since we have multiple 64-bit things that could
be referred to.
LP64 : integer=32, long=64, pointer=64
ILP64 : integer=64, long=64, pointer=64
This makes packages use lapack and blas, which can wrap different
BLAS/LAPACK implementations.
treewide: cleanup from blas/lapack changes
A few issues in the original treewide:
- can’t assume blas64 is a bool
- unused commented code
This is based on previous work for switching between BLAS and LAPACK
implementation in Debian[1] and Gentoo[2]. The goal is to have one way
to depend on the BLAS/LAPACK libraries that all packages must use. The
attrs “blas” and “lapack” are used to represent a wrapped BLAS/LAPACK
provider. Derivations that don’t care how BLAS and LAPACK are
implemented can just use blas and lapack directly. If you do care what
you get (perhaps for some CPP), you should verify that blas and lapack
match what you expect with an assertion.
The “blas” package collides with the old “blas” reference
implementation. This has been renamed to “blas-reference”. In
addition, “lapack-reference” is also included, corresponding to
“liblapack” from Netlib.org.
Currently, there are 3 providers of the BLAS and LAPACK interfaces:
- lapack-reference: the BLAS/LAPACK implementation maintained by netlib.org
- OpenBLAS: an optimized version of BLAS and LAPACK
- MKL: Intel’s unfree but highly optimized BLAS/LAPACK implementation
By default, the above implementations all use the “LP64” BLAS and
LAPACK ABI. This corresponds to “openblasCompat” and is the safest way
to use BLAS/LAPACK. You may received some benefits from “ILP64” or
8-byte integer BLAS at the expense of breaking compatibility with some
packages.
This can be switched at build time with an override like:
import <nixpkgs> {
config.allowUnfree = true;
overlays = [(self: super: {
lapack = super.lapack.override {
lapackProvider = super.lapack-reference;
};
blas = super.blas.override {
blasProvider = super.lapack-reference;
};
})];
}
or, switched at runtime via LD_LIBRARY_PATH like:
$ LD_LIBRARY_PATH=$(nix-build -E '(with import <nixpkgs> {}).lapack.override { lapackProvider = pkgs.mkl; is64bit = true; })')/lib:$(nix-build -E '(with import <nixpkgs> {}).blas.override { blasProvider = pkgs.mkl; is64bit = true; })')/lib ./your-blas-linked-binary
By default, we use OpenBLAS LP64 also known in Nixpkgs as
openblasCompat.
[1]: https://wiki.debian.org/DebianScience/LinearAlgebraLibraries
[2]: https://wiki.gentoo.org/wiki/Blas-lapack-switch
