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)

Am Mon, 11 Jun 2018 09:46:26 -0500
schrieb Jason Bacon <>:

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

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

We _could_ just ignore upstream and continue to use made-up numbers.
But everyone else having (or even in the case
of FreeBSD?!), while pkgsrc features with the same
contents, looks odd.

Can we get an explanation for why pkgsrc decided on .so.4?

Alrighty then,


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

Home | Main Index | Thread Index | Old Index