Actually set the soname

[giordano]

Ref: https://github.com/JuliaLinearAlgebra/libblastrampoline/pull/59#discussion_r795090192

Also, use major version instead of full version number, ref: https://github.com/JuliaLinearAlgebra/libblastrampoline/pull/59#discussion_r795040249

[giordano]

Note that with this, simply linking to blastrampoline results in:

% echo 'int main(){}'|cc -x c - -lblastrampoline -L.&&readelf -d a.out|grep NEEDED 
 0x0000000000000001 (NEEDED)             Shared library: [libblastrampoline.so.4]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

requiring the soname with the major version (libblastrampoline.so.4). We'd need to manually use patchelf to replace the needed name:

% patchelf --replace-needed libblastrampoline.so.4 libblastrampoline.so a.out 
% readelf -d a.out|grep NEEDED                                                    
 0x0000000000000001 (NEEDED)             Shared library: [libblastrampoline.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
% LD_LIBRARY_PATH=. ./a.out
%

[giordano]

The weird thing is that this library exposes "two APIs": the BLAS/LAPACK one, and the one to switch the library. The former is very stable, and the only one we care about when linking to this library in Yggdrasil, the latter is relevant for programs using the library to switch the BLAS implementation, and the one which may occasionally be broken.

[ViralBShah]

I think we should just care about the LBT API and not the BLAS/LAPACK one.

[staticfloat]

Mose's point is that most libraries that link against LBT don't care about the LBT-specific API, they only care about the BLAS/LAPACK API. So that means that they don't really care about the SOVERSION at all.

I'm not entirely sure what would happen if we patchelf a binary to depend on libblastrampoline.so; does that work with our JLL scheme? With normal paths, I figure it would work, because it search to see if lbt.so is loaded (it's not, lbt.so.4 is) so it would fall back to filesystem search, and find the symlink that loads lbt.so.4 (which is already loaded). But with JLLs, we in general don't set up those filesystem search paths, so I'm worried that we'd get dependency errors when trying to load something that's been patchelf'ed.

[giordano]

I'm quite confident this is the kind of cases where musl would get lost