Commit Graph
671 Commits
Author SHA1 Message Date
Jan Tojnar 91104b5417 Merge branch 'master' into staging-next 2020-08-23 02:00:50 +02:00
Silvan Mosberger 23962528ce Merge pull request #93703 from taktoa/master
osqp: init at 0.6.0
2020-08-20 02:03:08 +02:00
Matthew Bauer abba9a2154 nccl: 2.4.8-1 -> 2.7.8-1 2020-08-19 13:34:56 -05:00
Matthew Bauer 164f8024e9 cudatoolkit: init v11.0.3 2020-08-19 13:34:52 -05:00
Daniël de Kok 147e24dcd6 magma: 2.5.0 -> 2.5.3
Other changes:

- Move gfortran and cmake to nativeBuildInputs.
- Magma now (only) generates dynamic libraries by default.
- Use ninja for faster builds.
2020-08-18 11:18:08 +02: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 a49a59bc6c amd-libflame: init at 2.2
libflame is a protable library for dense matrix computations,
providing a complete LAPACK implementation. The AMD fork of libflame
is optimized for AMD CPUs.
2020-08-09 08:29:08 +02:00
Remy Goldschmidt c473490524 osqp: init at 0.6.0 2020-08-08 13:32:51 -07:00
Daniël de Kok 57d4c67fb8 Merge pull request #93052 from danieldk/amd-blis-zen-only
amd-blis: init at 2.2
2020-08-08 20:01:24 +02:00
R. RyanTM ca9c2e3548 petsc: 3.13.2 -> 3.13.3 2020-08-07 12:44:29 +10:00
Daniël de Kok 1474bfe27d Merge pull request #93653 from danieldk/mkl-2020.2.254
mkl: 2020.1.217 -> 2020.2.254
2020-08-05 08:08:08 +02:00
Pavol Rusnak 7839270bb0 or-tools: 7.6 -> 7.7 2020-07-26 15:34:17 +02:00
Daniël de Kok 6a236f5410 mkl: 2020.1.217 -> 2020.2.254 2020-07-22 17:38:07 +02:00
markuskowa 533720caa9 Merge pull request #93031 from andrew-d/andrew/dsd
dsd: init at 2018-07-01
2020-07-18 23:18:23 +02:00
Jack Coughlin 8a65fe8da6 petsc: Fix install_name_tool patch
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.
2020-07-18 08:47:24 -07:00
Andrew Dunham f856cb8a9e it++: init at 4.3.1 2020-07-16 17:59:24 -07:00
Daniël de Kok 4fbe92df09 amd-blis: init at 2.2
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.
2020-07-13 13:16:37 +02:00
Benjamin Hipple 2ec5479689 Merge pull request #89299 from wucke13/petsc
petsc: add fotran build argument
2020-07-07 13:50:29 -04:00
wucke13 dc5113fb06 petsc: 3.13.1 -> 3.13.2
+ add fortran build argument
2020-07-07 09:34:43 +02:00
Matthew Bauer 8a525d6a2b arpack: add blas, lapack to library path
Fixes #89215
2020-07-06 01:30:10 -04:00
R. RyanTM 669b2ab244 suitesparse-graphblas: 3.2.2 -> 3.3.0 2020-06-30 16:21:46 +00:00
R. RyanTM f79c05b113 openblas: 0.3.9 -> 0.3.10 2020-06-19 10:59:46 +02:00
Ryan Burns 92d7b38e89 openblas: enable on ppc64le 2020-10-02 18:10:44 -07:00
Doron Behar 60b4b396e5 Merge pull request #98501 from doronbehar/pkg/octave/arpack 2020-10-01 19:04:43 +03:00
Doron Behar bd77df6d6f arpack: assert that blas and lapack are compatible
Do it before buildInputs per:
https://github.com/NixOS/nixpkgs/pull/94892#discussion_r471110250

Remove unneed, BLAS_LIBS and LAPACK_LIBS from environment - the
libraries are detected just fine when in buildInputs.
2020-09-23 00:57:31 +03:00
Doron Behar e0d947c79c arpack: cosmetic changes
Don't use `with stdenv.lib` at the top of the expression, per:
https://nix.dev/anti-patterns/language.html#with-attrset-expression

Use rec and version inside `mkDerivation`, like almost any other
derivation.
2020-09-23 00:52:45 +03: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
Timo Kaufmann 346de1fb8c Merge pull request #87518 from r-ryantm/auto-update/sympow
sympow: 2.023.5 -> 2.023.6
2020-05-11 21:35:40 +00:00
R. RyanTM f66d997a29 sympow: 2.023.5 -> 2.023.6 2020-05-10 16:42:21 +00:00
Frederik Rietdijk d7cca0f356 Merge master into staging-next 2020-05-09 11:12:29 +02:00
R. RyanTM c0e63bc87e petsc: 3.13.0 -> 3.13.1 2020-05-08 15:57:25 +00: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
Jonathan Ringer c1e605dd6b openblas: also export unversioned libraries for linux 2020-05-08 06:52:02 +02:00
Mario Rodas a340a9f4d8 Merge pull request #86755 from andersk/abseil-ortools
abseil-cpp: 20191119 -> 20200225.2; or-tools: 7.5 -> 7.6
2020-05-07 06:53:54 -05:00
R. RyanTM 7a17b13b48 or-tools: 7.5 -> 7.6 2020-05-04 03:12:00 -07:00
Frederik Rietdijk 00bbfccecf Merge staging into staging-next 2020-05-01 09:28:45 +02:00
R. RyanTM 51b1533b37 suitesparse-graphblas: 3.2.1 -> 3.2.2 2020-05-01 09:06:34 +02:00
Markus Kowalewski 15cd0bd993 openblas: 0.3.8 -> 0.3.9 2020-05-01 09:02:51 +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 a6a502fca0 magma: remove mklSupport flag
This now relies on the "blas" and "lapack" packages.
2020-04-20 16:02:57 -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 fcf33e2499 scs: breaks on 64bit blas 2020-04-17 16:24:31 -05:00
Matthew Bauer 1c8aba8334 treewide: use blas and lapack
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
2020-04-17 16:24:09 -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
Matthew Bauer 90326ba624 lapack: enable shared libraries, cblas, and tests 2020-04-17 16:17:12 -05:00
R. RyanTM 1450740470 suitesparse: 5.7.1 -> 5.7.2 2020-04-10 11:55:20 -07:00
Benjamin Hipple a1f6400fd5 Merge pull request #84451 from robertodr/update-mkl
mkl: 2020.0.166 -> 2020.1.217 (Linux only)
2020-04-10 13:54:49 -04:00
Michael Reilly 84cf00f980 treewide: Per RFC45, remove all unquoted URLs 2020-04-10 17:54:53 +01:00
Mario Rodas 2f41064d86 Merge pull request #84455 from r-ryantm/auto-update/petsc
petsc: 3.12.4 -> 3.13.0
2020-04-08 21:35:27 -05:00