Hi,
Introduction: I am still working on proper BLAS support in pkgsrc … as
part of that I want to sort out what is installed from the LAPACK
distribution. This distribution contains (both current 3.7.1 in pkgsrc
and 3.8.0 in the wild):
- libblas (the BLAS library)
- liblapack (LAPACK, using BLAS)
- libcblas (BLAS C interface library)
- liblapacke (LAPACK C interface library)
- libtmg (test matrix generator … not handled by pkgsrc, AFAIK)
My intention is to have liblapack link to libblas (not decoupling them
for inserting better BLAS … as OpenBLAS and ALAS bring their own
LAPACK), but decouple libcblas and liblapacke so that one has a
build-time choice for the BLAS+LAPACK underlying those.
From the alternative BLAS packages, we opt to exclude any shipped
LAPACKE or CBLAS and rather use our generic packages for the wrapper
libs.
Now, I want to switch wip/cblas from it's stand-alone source to the
common LAPACK distribution. I observe the patches that insert use of
libtool to build shared libraries of libblas and liblapack … same for
libcblas. An unfortunate fact is the
-version-info 4:0
that we just throw in there. This results in libblas.so.4.0.0 being
installed. Version 4. I remember version 3 from elsewhere … also it
seems customary to use one common version number for the libraries
shipped together with LAPACK. Particulary, the alternate CMake build
system seems to manage that. From lapack-x.y.z, I thusly see
libblas.so.x.y.z
liblapack.so.x.y.z
libcblas.so.x.y.z
liblapacke.so.x.y.z
In pkgsrc, we have
libblas.so.4.0.0
liblapack.so.4.0.0
libcblas.so
When I replace libcblas with the source shipped with LAPACK, to ease
future maintenance and warrant that we have the Netlib stuff in sync
when updating math/lapack, I feel obliged to add a library version to
the shared lib. The ‘correct’ version for all of these seems to be
3.7.1, currently. After the next update, it should be 3.8.0. Both are
smaller than 4.0.0 and I guess that will not work very well when
upgrading …
Why does pkgsrc enforce version 4? Should I just continue with that,
disregarding that world+dog seems to expect libblas.so.3? It looks like
we got into a little bit of a mess here.
What is the good way out? Switch to the correct versions and add a
symlink to so.4 just to keep things rolling?
Besides, any opinion on the question whether we should try to use CMake
instead? I am not sure how easy hacking the thing into pieces is with
that. And as I said previously, I have a bit of a hate-hate
relationship with CMake.
Alrighty then,
Thomas
PS: I am grateful for some helpful responses, even if just to boost
morale. It is frustrating to hit these semantic road blocks when trying
to do the correct thing while our local patches to make packages just
use my wip/openblas work just as fine for _us_. I don't intend to run
Netlib BLAS, or Atlas, any time soon. Motivation to work on things that
don't bring actual benefit to oneself is not self-evident …