Hi, I am testing the CMake build of the netlib lapack package. I managed to get a build of libcblas and liblapacke that uses an installed OpenBLAS with such a build line: cmake \ -DCMAKE_C_FLAGS='-O3 -march=native' \ -DCMAKE_Fortran_FLAGS='-O3 -march=native' \ -DCMAKE_EXE_LINKER_FLAGS=-Wl,-R/stuff/src/OpenBLAS-0.2.20.libs \ -DCMAKE_SHARED_LINKER_FLAGS=-Wl,-R/stuff/src/OpenBLAS-0.2.20.libs \ -DBUILD_SHARED_LIBS=ON \ -DCMAKE_INSTALL_PREFIX=/dev/shm/lapack-test \ -DUSE_OPTIMIZED_BLAS=ON \ -DBLAS_LIBRARIES="-L/stuff/src/OpenBLAS-0.2.20.libs -lopenblas_openmp" \ -DUSE_OPTIMIZED_LAPACK=ON \ -DLAPACK_LIBRARIES="-L/stuff/src/OpenBLAS-0.2.20.libs -lopenblas_openmp" \ -DCBLAS=ON -DLAPACKE=ON \ ../lapack-3.8.0 Can someone tell me how much trouble it will be to get that into a pkgsrc package? Is there some default magic that inserts the usual values for installation prefixes and fumbles CFLAGS et al. in there when I set USE_TOOLS+=cmake? E.g. this line installs into $PREFIX/lib64 currently … so I wonder if I have to set the whole zoo of prefix variables in the package Makefile to hand to cmake. When using a BLAS/LAPACK from pkgsrc, I assume the BLAS_LIBRARIES="-L/pkgsrc_prefix -lopenblas_openmp" can be reduced to simply BLAS_LIBRARIES="-lopenblas_openmp". I think I could have a bit of fun with the RPATH settings, but probably it won't be an issue when everything resides in the common pkgsrc installation prefix … except libgfortran from a separate GCC installation prefix here … Anyway, I'd hope that such a direct build that supports shared libs will be leaner as a package, after dropping the patches that hacked this into the Makefiles. Once we have math/lapack switched to cmake, the difference between math/lapack, math/blas, wip/cblas, and wip/lapacke should just be the value of the CBLAS, LAPACKE USE_OPTIMIZED_LAPACK, USE_OPTIMIZED_BLAS options. And there is also the hook into supporting different implementations of BLAS and LAPACK with the cblas and lapacke interface libs. Still open questions: > We can trigger all dependent packages to be re-built, right? > How much of a no-go is an upgrade that replaces the .so.4 with an so.3 > and just tells users to rebuild things? Increment the revision of the > dependent packages as trigger to rebuild on update? … when I don't get a clear answer to those, I'll probably just create the .so.4 symlink. Alrighty then, Thomas -- Dr. Thomas Orgis Universität Hamburg RRZ / Basis-Infrastruktur / HPC Schlüterstr. 70 20146 Hamburg Tel.: 040/42838 8826 Fax: 040/428 38 6270
Attachment:
smime.p7s
Description: S/MIME cryptographic signature