Commit Graph

21 Commits

Author SHA1 Message Date
Vladimír Čunát
cb10bd6cb3
lapack: force a rebuild on x86_64-darwin
I have no idea why, but Hydra cached a corrupted binary
/nix/store/h0412qmi29ivgrc42lfhi1x290d6l429-lapack-3/lib/liblapack.dylib
so rebuilding it fixes issues in various dependants, e.g.
https://hydra.nixos.org/log/nqfq62pqbbmsq08kb2pljdkz9ldyr57b-python3.10-numpy-1.24.2.drv
2023-03-24 08:57:05 +01:00
Felix Buehler
cdb39a86e0 treewide: use optionalString 2023-02-13 21:52:34 +01:00
Markus Kowalewski
39210e89c2
lapack,blas: allow for more flexible use of ILP64 interface 2022-02-11 17:51:35 +01:00
Ellie Hermaszewska
8b136f75ca
lapack: include lapacke_utils.h in alternatives/lapack 2021-12-01 15:14:47 +08:00
github-actions[bot]
6a10b23c61
Merge staging-next into staging 2021-09-16 00:02:05 +00:00
Markus Kowalewski
20b905a8df
alternatives/blas: fix ILP64 check
This fix allows for MKL ILP64 builds.
2021-09-15 17:07:21 +02:00
Dmitry Kalinkin
b27cb06557
blas: fix library id on darwin for cblas 2021-09-02 21:38:18 -04:00
Dmitry Kalinkin
de4c61a515
blas: fix library id on darwin
dyld: lazy symbol binding failed: Symbol not found: _dsyevd_
  Referenced from: /nix/store/lr8grz1knmh6vc7j830gni0ka68qf1lk-xfitter-2.0.1/bin/xfitter
  Expected in: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
2021-08-23 21:33:50 -04:00
Pavol Rusnak
90f7338112
treewide: stdenv.lib -> lib 2021-01-24 01:49:49 +01:00
Frederik Rietdijk
d59c57f8a6
Merge pull request #92412 from matthewbauer/blas-cross
Blas/Lapack cross fixes
2020-08-15 08:55:57 +02:00
Daniël de Kok
68bd1c8552 blas: do not report an empty line for every checked symbol 2020-07-22 10:24:50 +02:00
Matthew Bauer
e7ea3de835 blas: use $NM instead of nm
This is the right one on cross compilation.
2020-07-06 00:25:32 -04:00
Daiderd Jordan
5ae928e18f
lapack: fix darwin library identifiers
The build system already sets these properly to the absolute path so no
need to patch the libraries on darwin.

    $ otool -D result/lib/liblapacke.dylib
    result/lib/liblapacke.dylib:
    /nix/store/k88gy5s765yn3dc5ws3jbykyvklm7z96-openblas-0.3.8/lib/libopenblasp-r0.3.8.dylib

Fixes #85713
2020-04-24 20:00:56 +02:00
Matthew Bauer
5a500ff0ba blas,lapack: use correct name for library
To match the soname, we need to use libblas.so.3, liblapack.so.3.
2020-04-22 12:37:04 -05:00
Matthew Bauer
8f58fa044d blas,lapack: symlink headers when using mkl
Some of these are necessary for things like python.pkgs.numexpr
2020-04-21 00:30:44 -05:00
Matthew Bauer
0caa375b4c blas,lapack: provide symlink for libmkl_rt.so
This is needed for numpy to detect mkl correctly.
2020-04-20 23:47:10 -05:00
Matthew Bauer
ff2f2644f8 blas,lapack: use isILP64 instead of is64bit
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
2020-04-20 16:02:43 -05:00
Matthew Bauer
3c9c894f83 blas,lapack: don’t patchelf
We have some unused RPATHs we don’t want shrunk. These are used in MKL
to dlopen based on architecture.
2020-04-20 15:50:28 -05:00
Sébastien Maret
712bf551d8 blas: fix build on darwin 2020-04-19 23:07:10 +02:00
Milan Pässler
fc5090b315 blas: fix build 2020-04-18 03:06:47 +02:00
Matthew Bauer
43873351ff 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-04-17 16:23:55 -05:00