lapack creates .mod files that are created in the same location
when the static and shared libraries these then interfere with each
other. put the .mod files created when buildling the static library
in a different directory to fix this.
This delivers 64 bit index BLAS libraries alongside 32 bit ones. This is often
called ILP64 in the BLAS world, as opposed to LP64 where integers are 32 bit
due to the Fortran default integer type, not to be confused with the basic
system ABI used by C. For really large vectors on modern machines, you want
an 'ILP64' BLAS and layers on top of it.
In preparation of better support for vendor BLAS libraries, I had to realize
that you better use the C interfaces supplied by them, not the netlib one
strapped on. A simple reason of practicability: The vendor blas libraries,
just like openblas, like to ship all symbols in one library, so you get them
whether you want it or not. Also implementations may skip Fortran and implement
the underlying functionality directly in C anyway, so one might skip a
layer of indirection. Future will tell if other layers will follow. We still
have the framework of individual layers from Netlib to combine with certain
implementations that miss them (Accelerate framework comes to mind, which
needs further work).
The framework of netlib reference packages for the separate libraries
is instructive and helps keeping things small when you not need all of them.
The installation location of the headers is now in a subdirectory to be able
to have 32 and 64 bit variants independently. The 32 bit ones are linked to
${PREFIX}/include to keep the old picture. We could be brave and remove
those, but there is some value in a build just trying -lcblas and
inclusion of <cblas.h> to be happy.
There is one blas.buildlink3.mk that is supposed to be used only once and
so avoids a combination of conflicting libraries (as the 64 bit index symbols
have the same names as the 32 bit ones).
Basic usage for getting LAPACK+BLAS is still the same as before. You get
CBLAS and LAPACKE by setting BLAS_C_INTERFACE=yes in the package. The 64 bit
indices are selected via BLAS_INDEX64=yes.
Due to the special nature of the Accelerate framework, a package has to
explicitly indicate support for it and it will also not appear on the
list of implementations by default. The reason is that it does provide
mainly CBLAS and CLAPACK (another version of C interface to LAPACK, f2c-based)
and BLAS/LAPACK with f2c/g77 calling conventions. A default build with
gfortran would not like that
This commit also fixes up math/py-numpy and math/py-numpy16 to follow the
new scheme, as that are the only packages directly affected by the change
in CBLAS providership.
Those cmake config files are not useful for us and they are incorrect
for the upcoming 64-bit-index variants. Also, we could switch back
to the Makefile build from cmake in future. Let's treat the question of
CMake as implementation detail of the packages.
The actual use is via mk/blas.bl3 in pkgsrc and pkg-config. There isn't
even added value in these files, were they to be correct. CMake builds
can use pkg-config just fine.
The upcoming lapack64 needs the library name liblapack64, the
variable for that was missing in the patch. This does not change
the build of math/lapack itself.
This was lost on the recent rework of the patches:
On NetBSD.
In PKGSRC_FORTRAM=gfortran case, libcblas has no RPATH=/usr/pkg/gccXX/lib
and libgfortran and libquadmath are not found.
In PKGSRC_FORTRAN=g95 case, libcblas has no
RPATH=/usr/pkg/lib/gcc-lib/x86_64--netbsd/4.1.2 and libf95 is not found.
Use Fortran compiler as linker instread of C compiler to fix link.
On NetBSD.
In PKGSRC_FORTRAM=gfortran case, libcblas has no RPATH=/usr/pkg/gccXX/lib
and libgfortran and libquadmath are not found.
In PKGSRC_FORTRAN=g95 case, libcblas has no
RPATH=/usr/pkg/lib/gcc-lib/x86_64--netbsd/4.1.2 and libf95 is not found.
Use Fortran compiler as linker instread of C compiler to fix link.
Install the new interchangeable BLAS system created by Thomas Orgis,
currently supporting Netlib BLAS/LAPACK, OpenBLAS, cblas, lapacke, and
Apple's Accelerate.framework. This system allows the user to select any
BLAS implementation without modifying packages or using package options, by
setting PKGSRC_BLAS_TYPES in mk.conf. See mk/blas.buildlink3.mk for details.
This commit should not alter behavior of existing packages as the system
defaults to Netlib BLAS/LAPACK, which until now has been the only supported
implementation.
Details:
Add new mk/blas.buildlink3.mk for inclusion in dependent packages
Install compatible Netlib math/blas and math/lapack packages
Update math/blas and math/lapack MAINTAINER approved by adam@
OpenBLAS, cblas, and lapacke will follow in separate commits
Update direct dependents to use mk/blas.buildlink3.mk
Perform recursive revbump
Have switched to the CMAKE build and enabled tests.
make test passes all (with one patch pushed upstream)
Package additions, from the release notes are:
LAPACK 3.9.0
LAPACK QR
preconditioned QR SVD method for computing the SVD with high accuracy,
by Zlatko Drmac
LAPACK Householder Reconstruction
by Igor Kozachenko and Jim Demmel
LAPACK 3.8.0
Symmetric-indefinite Factorization: Aasen’s tridiagonalization 2 stage
A contribution from Ichitaro Yamazaki (University of Tennessee).
LAPACKE interfaces
A contribution from Julie Langou (University of Tennessee).
pkglint -r --network --only "migrate"
As a side-effect of migrating the homepages, pkglint also fixed a few
indentations in unrelated lines. These and the new homepages have been
checked manually.
* Linear Least Squares / Minimum Norm solution
* Symmetric-indefinite Factorization: Aasen’s tridiagonalization
* Symmetric-indefinite Factorization: New storage format for L factor in Rook Pivoting and Bunch Kaufman of LDLT
* Symmetric eigenvalue problem: Two-stage algorithm for reduction to tridiagonal form
* Improved Complex Jacobi SVD
* LAPACKE interfaces
Linking lapack with the gold linker fails with this error:
fatal error: --sysroot=: must take a non-empty argument
DragonFly has been using the gold linker by default for a while now.
Since I don't have time to track down this linking problem, I'm going
to restore the build on DragonFly by setting an environment variable
that forces DF to use the classic GNU linker instead.
This was already fixed on math/blas which uses the lapack common
makefile, so just relocate the fix to lapack.
LAPACK 3.6.1: What’s new
[Mark Gates, UTK] blocked back-transformation for the non-symmetric eigenvalue problem
It blocks NB gemv calls into one gemm call inside trevc. To do
that, it needs a new routine, trevc3, because unfortunately the
lwork was not passed into trevc. Attached is the performance speedup
for dgeev. It gives a nice 1.5x speedup for N=20000, and that
appears to still be increasing with N. This is not the improvements
that Greg Henry recently provided for doing the triangular solves
as BLAS-3 instead of BLAS-1. That will take a while to process,
but we expect another, even larger increase in performance when
those changes are applied. This also does not include doing multiple
(BLAS-1) triangular solves in parallel, which is available in MAGMA,
since that requires OpenMP or pthreads.
* added Symmetric/Hermitian LDLT factorization routines with rook pivoting algorithm
* 2-by-1 CSD to be used for tall and skinny matrix with orthonormal columns (in LAPCK 3.4.0, we already integrated CSD of a full square orthogonal matrix)
* New stopping criteria for balancing.
This changes the buildlink3.mk files to use an include guard for the
recursive include. The use of BUILDLINK_DEPTH, BUILDLINK_DEPENDS,
BUILDLINK_PACKAGES and BUILDLINK_ORDER is handled by a single new
variable BUILDLINK_TREE. Each buildlink3.mk file adds a pair of
enter/exit marker, which can be used to reconstruct the tree and
to determine first level includes. Avoiding := for large variables
(BUILDLINK_ORDER) speeds up parse time as += has linear complexity.
The include guard reduces system time by avoiding reading files over and
over again. For complex packages this reduces both %user and %sys time to
half of the former time.
and add a new helper target and script, "show-buildlink3", that outputs
a listing of the buildlink3.mk files included as well as the depth at
which they are included.
For example, "make show-buildlink3" in fonts/Xft2 displays:
zlib
fontconfig
iconv
zlib
freetype2
expat
freetype2
Xrender
renderproto
