Commit graph

28 commits

Author SHA1 Message Date
Ben Siraphob 02ee14b9d5 treewide: stdenvNoCC.lib -> lib 2021-01-27 13:01:51 +07:00
John Ericson f52263ced0 treewide: Start to break up static overlay
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
2021-01-03 19:18:16 +00:00
Daniël de Kok 5d8ae7e7b3 mkl: 2020.3.279 -> 2020.4.304
Release notes:

https://software.intel.com/content/www/us/en/develop/articles/intel-math-kernel-library-release-notes-and-new-features.html
2020-11-29 08:42:33 +01:00
Daniël de Kok b5d27eb87c mkl: Add a small test program
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.
2020-11-06 12:18:56 +01:00
Daniël de Kok 702b626570 mkl: Fix pkg-config file
There was a spurious `intel64` in some library paths.
2020-11-06 09:55:12 +01:00
Daniël de Kok 405f49dc4a mkl: 2020.2.254 -> 2020.3.279
Release notes:

https://software.intel.com/content/www/us/en/develop/articles/intel-math-kernel-library-release-notes-and-new-features.html
2020-09-03 15:29:10 +02:00
Daniël de Kok 6a236f5410 mkl: 2020.1.217 -> 2020.2.254 2020-07-22 17:38:07 +02:00
Daniël de Kok 127cdd0cab mkl: use validatePkgConfig hook 2020-05-31 20:45:07 +02:00
Daniël de Kok e88673aa27 mkl: fix expectation of MKLROOT being set in pkg-config files
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.
2020-05-14 19:40:18 +02:00
Benjamin Hipple 706642091e mkl: include symlinks to versioned libblas.so.3 names
Some build systems look for this specifically.
2020-05-08 06:52:02 +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 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
Roberto Di Remigio 488527eaa6
mkl: 2020.0.166 -> 2020.1.217 2020-04-06 11:57:22 +02:00
Roberto Di Remigio 335e097352
mkl: 2019.5.281 -> 2020.0.166 (Linux only) 2020-03-27 08:45:20 +01:00
Roberto Di Remigio 153597a320
mkl: filter static libs in installPhase 2019-12-19 10:23:26 +01:00
Roberto Di Remigio 6cc9bbe2fd
mkl: extract static libraries optionally 2019-12-19 10:12:00 +01:00
Roberto Di Remigio e0605b3174
mkl: add GNU threading and Fortran libraries
Signed-off-by: Roberto Di Remigio <roberto.diremigio@gmail.com>
2019-12-19 10:12:00 +01:00
Markus Kowalewski d817a49faa
mkl: add scalapack libraries to output 2019-11-18 09:05:03 +01:00
Benjamin Hipple fa1e275f31 mkl: 2019.3 -> 2019.5 (#71476)
Includes bugfixes, new features, and performance improvements.

Full release notes here:
https://software.intel.com/en-us/articles/intel-math-kernel-library-release-notes-and-new-features

Leave Darwin on 2019.3 pending resolution of DMG issues
2019-10-27 15:34:16 -04:00
Daniël de Kok 9f25e95576 mkl: include pkgconfig files 2019-09-22 20:07:34 +02:00
volth f3282c8d1e treewide: remove unused variables (#63177)
* treewide: remove unused variables

* making ofborg happy
2019-06-16 19:59:05 +00:00
Sébastien Maret fb883a58df
mkl: fix install_name on Darwin
Closes #57697

Co-Authored-By: Dmitry Kalinkin <dmitry.kalinkin@gmail.com>
2019-06-04 22:08:48 +02:00
Markus Kowalewski 734c6c21cb
mkl: 2019.0.117 -> 2019.3.199 2019-04-01 21:50:23 +02:00
agracie a3fc481b76 mkl: fix hash on Darwin 2018-12-26 20:57:08 -05:00
Benjamin Hipple 6206a342e0 mkl: include Intel's libiomp.so in the MKL RPM unpack
Since Intel's default openmp implementation is available in the same src
tarball, we can just include it in the package. This means that `mkl` now "just
works" without any environment variables, fragile setup-hooks, or forced
propagation.

Since the openmp implementation is only needed at runtime (and for test cases),
users can substitute a different one if they prefer by exporting it with
`LD_PRELOAD`, which is how Intel recommends handling this. If they do not do so,
`libiomp.so` lives next to `libmkl_rt.so` and thus will be in the RPATH as a
sane default.

Since this still comes from the same src tarball, we can ship it without losing
the fixed-output derivation; likewise, since Hydra is not building or caching
these, shipping these proprietary packages costs no bandwidth for the nix
community.
2018-12-19 22:05:22 +01:00
Benjamin Hipple 0b82df8dbe Convert entire mkl package to a fixed-output derivation 2018-10-04 13:16:20 +00:00
Benjamin Hipple ba02a2c371 Add Darwin as a supported platform 2018-10-02 22:53:48 -04:00
Benjamin Hipple d7c1d04af4 mkl: init at 2019.0.117
This packags the Intel Math Kernel library on x86-64 platforms, which is a
dependency for many data science and machine learning packages.

Upstream, Intel provides proprietary binary RPMs with a permissive
redistribution license. These have been repackaged in both Debian and Anaconda,
so we are not the first distribution to redistribute.
2018-09-22 15:28:39 -04:00