tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re:, etc. version numbers? (working on wip/cblas and wip/lapacke)

On 06/08/18 10:50, Dr. Thomas Orgis wrote:

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

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 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

In pkgsrc, we have

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 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,


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 …

The soversion doesn't necessarily correspond to the major distversion.

It appears that Netlib BLAS and LAPACK don't even have a concept of soversions upstream and this may be somewhat arbitrarily tacked on by the package manager for its own purposes.

I just looked at the FreeBSD port for perspective and it uses an soversion of 1 for the lapacke slave port, 2 for the blas slave port, and 4 for the lapack master.  The cblas port forces an soversion of 2.

Interestingly, lapacke is an lapack slave, but cblas is not.  Both get their sources from netlib, though,
as does pkgsrc-wip cblas.

I'd like to hear from the blas/lapack maintainer(s) on the soversion.

What would be the benefit of using cmake?  Unless it's significant (e.g. upstream plans to require it in the near future),
I wouldn't want to add such a big and painful dependency.



Home | Main Index | Thread Index | Old Index