nixpkgs/pkgs/build-support/alternatives/blas/default.nix

142 lines
5.5 KiB
Nix
Raw Normal View History

blas/lapack: add wrapper for “alternative”s of BLAS/LAPACK provider 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
2020-03-27 19:50:45 +01:00
{ lib, stdenv
, lapack-reference, openblasCompat, openblas
, isILP64 ? false
, blasProvider ? if isILP64 then openblas else openblasCompat }:
blas/lapack: add wrapper for “alternative”s of BLAS/LAPACK provider 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
2020-03-27 19:50:45 +01:00
let
blasFortranSymbols = [
"caxpy" "ccopy" "cdotc" "cdotu" "cgbmv" "cgemm" "cgemv" "cgerc" "cgeru"
"chbmv" "chemm" "chemv" "cher" "cher2" "cher2k" "cherk" "chpmv" "chpr"
"chpr2" "crotg" "cscal" "csrot" "csscal" "cswap" "csymm" "csyr2k" "csyrk"
"ctbmv" "ctbsv" "ctpmv" "ctpsv" "ctrmm" "ctrmv" "ctrsm" "ctrsv" "dasum"
"daxpy" "dcabs1" "dcopy" "ddot" "dgbmv" "dgemm" "dgemv" "dger" "dnrm2"
"drot" "drotg" "drotm" "drotmg" "dsbmv" "dscal" "dsdot" "dspmv" "dspr"
"dspr2" "dswap" "dsymm" "dsymv" "dsyr" "dsyr2" "dsyr2k" "dsyrk" "dtbmv"
"dtbsv" "dtpmv" "dtpsv" "dtrmm" "dtrmv" "dtrsm" "dtrsv" "dzasum" "dznrm2"
"icamax" "idamax" "isamax" "izamax" "lsame" "sasum" "saxpy" "scabs1"
"scasum" "scnrm2" "scopy" "sdot" "sdsdot" "sgbmv" "sgemm" "sgemv"
"sger" "snrm2" "srot" "srotg" "srotm" "srotmg" "ssbmv" "sscal" "sspmv"
"sspr" "sspr2" "sswap" "ssymm" "ssymv" "ssyr" "ssyr2" "ssyr2k" "ssyrk"
"stbmv" "stbsv" "stpmv" "stpsv" "strmm" "strmv" "strsm" "strsv" "xerbla"
"xerbla_array" "zaxpy" "zcopy" "zdotc" "zdotu" "zdrot" "zdscal" "zgbmv"
"zgemm" "zgemv" "zgerc" "zgeru" "zhbmv" "zhemm" "zhemv" "zher" "zher2"
"zher2k" "zherk" "zhpmv" "zhpr" "zhpr2" "zrotg" "zscal" "zswap" "zsymm"
"zsyr2k" "zsyrk" "ztbmv" "ztbsv" "ztpmv" "ztpsv" "ztrmm" "ztrmv" "ztrsm"
"ztrsv"
];
version = "3";
canonicalExtension = if stdenv.hostPlatform.isLinux
then "${stdenv.hostPlatform.extensions.sharedLibrary}.${version}"
else stdenv.hostPlatform.extensions.sharedLibrary;
isILP64 = blasProvider.blas64 or false;
blas/lapack: add wrapper for “alternative”s of BLAS/LAPACK provider 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
2020-03-27 19:50:45 +01:00
blasImplementation = lib.getName blasProvider;
in
assert isILP64 -> (blasImplementation == "openblas" && blasProvider.blas64) || blasImplementation == "mkl";
blas/lapack: add wrapper for “alternative”s of BLAS/LAPACK provider 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
2020-03-27 19:50:45 +01:00
stdenv.mkDerivation {
pname = "blas";
inherit version;
outputs = [ "out" "dev" ];
meta = (blasProvider.meta or {}) // {
description = "${lib.getName blasProvider} with just the BLAS C and FORTRAN ABI";
};
passthru = {
inherit isILP64;
blas/lapack: add wrapper for “alternative”s of BLAS/LAPACK provider 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
2020-03-27 19:50:45 +01:00
provider = blasProvider;
implementation = blasImplementation;
};
dontBuild = true;
dontConfigure = true;
unpackPhase = "src=$PWD";
dontPatchELF = true;
blas/lapack: add wrapper for “alternative”s of BLAS/LAPACK provider 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
2020-03-27 19:50:45 +01:00
installPhase = (''
2020-04-18 03:06:47 +02:00
mkdir -p $out/lib $dev/include $dev/lib/pkgconfig
blas/lapack: add wrapper for “alternative”s of BLAS/LAPACK provider 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
2020-03-27 19:50:45 +01:00
libblas="${lib.getLib blasProvider}/lib/libblas${canonicalExtension}"
blas/lapack: add wrapper for “alternative”s of BLAS/LAPACK provider 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
2020-03-27 19:50:45 +01:00
if ! [ -e "$libblas" ]; then
echo "$libblas does not exist, ${blasProvider.name} does not provide libblas."
exit 1
fi
$NM -an "$libblas" | cut -f3 -d' ' > symbols
blas/lapack: add wrapper for “alternative”s of BLAS/LAPACK provider 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
2020-03-27 19:50:45 +01:00
for symbol in ${toString blasFortranSymbols}; do
grep -q "^$symbol_$" symbols || { echo "$symbol" was not found in "$libblas"; exit 1; }
blas/lapack: add wrapper for “alternative”s of BLAS/LAPACK provider 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
2020-03-27 19:50:45 +01:00
done
cp -L "$libblas" $out/lib/libblas${canonicalExtension}
chmod +w $out/lib/libblas${canonicalExtension}
'' + (if stdenv.hostPlatform.parsed.kernel.execFormat.name == "elf" then ''
patchelf --set-soname libblas${canonicalExtension} $out/lib/libblas${canonicalExtension}
patchelf --set-rpath "$(patchelf --print-rpath $out/lib/libblas${canonicalExtension}):${lib.getLib blasProvider}/lib" $out/lib/libblas${canonicalExtension}
'' else if stdenv.hostPlatform.isDarwin then ''
install_name_tool \
2020-04-19 23:07:10 +02:00
-id libblas${canonicalExtension} \
blas/lapack: add wrapper for “alternative”s of BLAS/LAPACK provider 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
2020-03-27 19:50:45 +01:00
-add_rpath ${lib.getLib blasProvider}/lib \
$out/lib/libblas${canonicalExtension}
'' else "") + ''
if [ "$out/lib/libblas${canonicalExtension}" != "$out/lib/libblas${stdenv.hostPlatform.extensions.sharedLibrary}" ]; then
ln -s $out/lib/libblas${canonicalExtension} "$out/lib/libblas${stdenv.hostPlatform.extensions.sharedLibrary}"
fi
cat <<EOF > $dev/lib/pkgconfig/blas.pc
Name: blas
Version: ${version}
Description: BLAS FORTRAN implementation
Libs: -L$out/lib -lblas
Cflags: -I$dev/include
EOF
libcblas="${lib.getLib blasProvider}/lib/libcblas${canonicalExtension}"
blas/lapack: add wrapper for “alternative”s of BLAS/LAPACK provider 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
2020-03-27 19:50:45 +01:00
if ! [ -e "$libcblas" ]; then
echo "$libcblas does not exist, ${blasProvider.name} does not provide libcblas."
exit 1
fi
cp -L "$libcblas" $out/lib/libcblas${canonicalExtension}
chmod +w $out/lib/libcblas${canonicalExtension}
'' + (if stdenv.hostPlatform.parsed.kernel.execFormat.name == "elf" then ''
patchelf --set-soname libcblas${canonicalExtension} $out/lib/libcblas${canonicalExtension}
patchelf --set-rpath "$(patchelf --print-rpath $out/lib/libcblas${canonicalExtension}):${lib.getLib blasProvider}/lib" $out/lib/libcblas${canonicalExtension}
'' else if stdenv.hostPlatform.isDarwin then ''
install_name_tool \
-id libcblas${canonicalExtension} \
-add_rpath ${lib.getLib blasProvider}/lib \
$out/lib/libcblas${canonicalExtension}
'' else "") + ''
if [ "$out/lib/libcblas${canonicalExtension}" != "$out/lib/libcblas${stdenv.hostPlatform.extensions.sharedLibrary}" ]; then
ln -s $out/lib/libcblas${canonicalExtension} "$out/lib/libcblas${stdenv.hostPlatform.extensions.sharedLibrary}"
fi
cp ${lib.getDev lapack-reference}/include/cblas{,_mangling}.h $dev/include
cat <<EOF > $dev/lib/pkgconfig/cblas.pc
Name: cblas
Version: ${version}
Description: BLAS C implementation
Cflags: -I$dev/include
Libs: -L$out/lib -lcblas
EOF
2021-01-24 01:40:18 +01:00
'' + lib.optionalString (blasImplementation == "mkl") ''
blas/lapack: add wrapper for “alternative”s of BLAS/LAPACK provider 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
2020-03-27 19:50:45 +01:00
mkdir -p $out/nix-support
echo 'export MKL_INTERFACE_LAYER=${lib.optionalString isILP64 "I"}LP64,GNU' > $out/nix-support/setup-hook
ln -s $out/lib/libblas${canonicalExtension} $out/lib/libmkl_rt${stdenv.hostPlatform.extensions.sharedLibrary}
ln -sf ${blasProvider}/include/* $dev/include
blas/lapack: add wrapper for “alternative”s of BLAS/LAPACK provider 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
2020-03-27 19:50:45 +01:00
'');
}