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