Am Mon, 11 Jun 2018 09:46:26 -0500
schrieb Jason Bacon <outpaddling%yahoo.com@localhost>:
The soversion doesn't necessarily correspond to the major distversion.
Yep. I manage mpg123, where the library is at 0.44.6 for project
version 1.25.7. Re-reading documentation about library version numbers
suggests to me that not making the distinction mainly excludes the
option to have a backwards-compatible major version increment. As long
as they never introduce LAPACK 4.x, things will work out … well and as
long as nobody prematurely started shipping builds of the libraries
with made-up soversions.
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.
Spot on … at least for the Makefile-based build. Pkgsrc just hacks
the shared lib builds with patches.
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.
Wonderful mess we got there. Did you ask them?
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.
Agreed. But using cmake, we can discern what netlib folks might think
about regarding shared libraries and versioning:
$cmake -DBUILD_SHARED_LIBS=ON ../lapack-3.7.1
…
$find . -name '*.so*'
./lib/libblas.so.3.7.1
./lib/liblapack.so.3
./lib/libblas.so
./lib/liblapack.so
./lib/libtmglib.so
./lib/libblas.so.3
./lib/liblapack.so.3.7.1
There now is the precedence of just putting the project
version number in there, implying that a future version 4.x will be
ABI-incompatible … and we might have to switch from 4.0 to 3.7.1 or
3.8.0.
We _could_ just ignore upstream and continue to use made-up numbers.
But everyone else having libblas.so.3 (or even libblas.so.2 in the case
of FreeBSD?!), while pkgsrc features libblas.so.4 with the same
contents, looks odd.
Can we get an explanation for why pkgsrc decided on .so.4?
Alrighty then,
Thomas