Next | Query returned 82 messages, browsing 11 to 20 | Previous

History of commit frequency

CVS Commit History:


   2021-10-07 16:28:36 by Nia Alarie | Files touched by this commit (458)
Log message:
math: Remove SHA1 hashes for distfiles
   2021-06-15 17:06:24 by Dr. Thomas Orgis | Files touched by this commit (2)
Log message:
math/lapack, math/openblas: more inclusive 64 bit platform check

The simple approach missed alpha.
   2021-06-15 06:41:53 by Dr. Thomas Orgis | Files touched by this commit (36)
Log message:
mk/blas.bl3, Netlib and OpenBLAS packages, NumPy: C fixup and 64 bits

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.
   2021-06-10 02:18:53 by Dr. Thomas Orgis | Files touched by this commit (7)
Log message:
math/lapack, math/cblas, math/lapacke: Remove premature cmake files from install

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.
   2021-06-02 00:14:09 by Dr. Thomas Orgis | Files touched by this commit (1)
Log message:
math/lapacke: distinfo for the changed patch
   2021-06-02 00:13:35 by Dr. Thomas Orgis | Files touched by this commit (1)
Log message:
math/lapack: fix static library name preparing for lapack64

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.
   2021-05-17 13:31:29 by Dr. Thomas Orgis | Files touched by this commit (2)
Log message:
math/lapack: remove spurious hook from lokal build in  CMake patch

This added a rather irrelevant local search path and just polluted
the patch with a local directory from by builds.
   2021-05-13 09:52:05 by Dr. Thomas Orgis | Files touched by this commit (3)
Log message:
cblas: Restore: Fix link to Fortran libraries by using Fortran compiler as linker

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.
   2021-05-12 16:32:52 by Dr. Thomas Orgis | Files touched by this commit (12) | Package updated
Log message:
math/lapack, blas, cblas, lapacke: update to version 3.9.1

This includes a rework of the build system patches, which I'll try
to push upstream …
   2021-04-21 15:53:19 by Ryo ONODERA | Files touched by this commit (2)
Log message:
cblas: Fix link to Fortran libraries by using Fortran compiler as linker

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.

Next | Query returned 82 messages, browsing 11 to 20 | Previous