On Wed, 2021-05-05 at 14:57 +0200, Drew Parsons wrote: > > > The "disaster" is that they can point to different implementations. > So > if you check the symlinks for libblas.so, you think you're using one > implementation, while the different libblas.so.3 means you're > actually > running against another implementation. So it's not a build disaster > as > such, since they keep ABI compatibility. But it is a system > maintenance > disaster in the sense that it makes it harder than it needs to be to > keep track of which BLAS is actually running on the system.
A sensible way to check which implementation is actually used is to follow the logic of the dynamic linker (see ld.so(8) and elf(5)). It loads libraries specified by the ELF header as NEEDED (readelf) or DT_NEEDED (ld.so(8), elf(5)). As specifying `libblas.so` without SOVERSION would very likely trigger a lintian Error, I think all blas/lapack reverse dependencies won't care about at which implementation on earth is symlink libblas.so pointing. I think this applies to all ELF binaries in the Debian archive. Of course, FFI/dlopen is not the case to discuss here. > > The libblas.so alternative only matters when you’re doing static > > linking, since that alternative also governs libblas.a. But we > > don’t > > use static linking much in Debian. And for someone who is doing > > static > > linking, the libblas.so.3 alternative is irrelevant anyways, so > > there > > is no risk of confusion. > > OK, if libblas.so controls libblas.a, then it's more meaningful. > Though > still odd to have static symbols handled by one implementation, and > dynamic symbols by another. Are there any cases where that would be > desirable? There may be room for further improvement. But the first question came up in my mind is: how to manage differnt header files (e.g. cblas.h) and static libs exported by different implementations without introducing further confusions? For example, BLAS implemtations (except for BLIS and MKL) in our archive provide libblas.a. When we switch BLAS to BLIS or MKL, that libblas.a symlink exposed under /usr/lib/<triplet>/ will be automatically hidden, and the linker won't find it from the default search path. So users won't accidentally make Without the current alternatives mechanism, can we find a better solution to avoid the situation where the libblas.a from the reference implementation and the cblas.h header from MKL are exposed at the same time?
