tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Warning about BLAS choice and math/arpack-ng (needed for math/octave).
Dear all,
of course I notice this bug right now during branching. The new BLAS
infrastructure is in place and facilitates choice of an implementation
to get faster software for a number of packages. The new choice has a
stumbling block in math/arpack-ng, which is used for math/octave.
Arpack-ng used to directly depend on the netlib BLAS. Both it and
octave itself now make use of the central blas.bl3, but I have to
notice that arpack-ng uses a FindBLAS.cmake delivered with current
CMake and which is blind to our machinery. I'll do a commit after the
branch that at least allows netlib and openblas as valid choices (not
openblas_openmp, for example), as those map to one of the hardcoded
options FindBLAS.cmake has.
For now, things still work fine if the user (or bulk builder) doesn't
touch PKGSRC_BLAS_TYPES, resulting in the default of using Netlib stuff
(math/blas and friends). With a differing setting, you either get a build
failure of math/arpack-ng or this situation:
$ ldd /data/pkg/lib/octave/6.2.0/liboctave.so|grep blas
libopenblas_openmp.so.0 => /data/pkg/lib/libopenblas_openmp.so.0 (0x00007fcc747f6000)
libblas.so.3 => /data/pkg/lib/libblas.so.3 (0x00007fcc73ad8000)
I think this should result in the desired end: Using the symbols from
libopenblas_openmp.so, but this is no clean situation, of course.
I am investigating the possibility to work with CMake upstream to make
FindBLAS.cmake more helpful for the case where we want to choose a
specific library with a name we set. The simplest thing probably would
be to make it use a pkg-config file, as it already has a path for the
generic case of some blas.pc.
Maybe we can ensure that all BLAS variants install a proper pkg-config
file and thus simplify mk.bl3 a bit, too. I see Intel MKL also
providing .pc files, but not for all possible configurations we might
want. I imagine a math/blaswrap package anyway, which would provide
cblas.h that includes mkl_cblas.h with the proper defines … it could
also install some .pc files for the configurations we need, to keep
mk.bl3 lean. Basically, a support package that installs some text files
to work with implementations that don't or who we don't trust in that
respect. The Accelerate framework could also get a .pc file that way, I
guess.
You could chime in here and stop me early in the tracks if
you think that's a bad idea;-)
Alrighty then,
Thomas
--
Dr. Thomas Orgis
HPC @ Universität Hamburg
Home |
Main Index |
Thread Index |
Old Index