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