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