about summary refs log tree commit diff
path: root/pkgs/build-support/alternatives
AgeCommit message (Collapse)AuthorFilesLines
2024-01-07treewide: simplify exec format conditionalsRyan Burns2-4/+4
2023-03-24lapack: force a rebuild on x86_64-darwinVladimír Čunát1-0/+3
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-02-13treewide: use optionalStringFelix Buehler2-8/+8
2022-02-11lapack,blas: allow for more flexible use of ILP64 interfaceMarkus Kowalewski2-27/+33
2021-12-01lapack: include lapacke_utils.h in alternatives/lapackEllie Hermaszewska1-1/+1
2021-09-16Merge staging-next into staginggithub-actions[bot]1-1/+0
2021-09-15alternatives/blas: fix ILP64 checkMarkus Kowalewski1-1/+0
This fix allows for MKL ILP64 builds.
2021-09-02blas: fix library id on darwin for cblasDmitry Kalinkin1-1/+1
2021-08-23blas: fix library id on darwinDmitry Kalinkin1-1/+1
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-01-24treewide: stdenv.lib -> libPavol Rusnak2-2/+2
2020-08-15Merge pull request #92412 from matthewbauer/blas-crossFrederik Rietdijk1-1/+1
Blas/Lapack cross fixes
2020-07-22blas: do not report an empty line for every checked symbolDaniël de Kok1-1/+1
2020-07-06blas: use $NM instead of nmMatthew Bauer1-1/+1
This is the right one on cross compilation.
2020-04-24lapack: fix darwin library identifiersDaiderd Jordan1-8/+0
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-22blas,lapack: use correct name for libraryMatthew Bauer2-4/+4
To match the soname, we need to use libblas.so.3, liblapack.so.3.
2020-04-21blas,lapack: symlink headers when using mklMatthew Bauer2-0/+2
Some of these are necessary for things like python.pkgs.numexpr
2020-04-20blas,lapack: provide symlink for libmkl_rt.soMatthew Bauer2-0/+2
This is needed for numpy to detect mkl correctly.
2020-04-20blas,lapack: use isILP64 instead of is64bitMatthew Bauer2-11/+11
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-20blas,lapack: don’t patchelfMatthew Bauer2-0/+4
We have some unused RPATHs we don’t want shrunk. These are used in MKL to dlopen based on architecture.
2020-04-19blas: fix build on darwinSébastien Maret1-1/+1
2020-04-18blas: fix buildMilan Pässler1-1/+1
2020-04-17blas/lapack: add wrapper for “alternative”s of BLAS/LAPACK providerMatthew Bauer2-0/+248
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
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-07-05 22:38:10 +0000