Hi, Some updates.
On Thu, 2025-09-11 at 20:07 +0200, Michał Górny wrote: > We get the best of both worlds: packages can use the complete API, we > use the preferred provider when we can, and fall back when we can't. > On top of that, unlike with eselect, the preferred provider can be > overriden via user configuration and environment variables too. We're currently blocked on missing xerbla_array_ function, but upstream promised to add it for us. On the positive side, it looks like FlexiBLAS also implements functions specific to OpenBLAS that Netlib LAPACK doesn't have, so we'll be able to remove the OpenBLAS hack from dev-python/qiskit-aer. > On the minus side, FlexiBLAS currently doesn't support the mixed > LP64/ILP64 interface provided by the latest sci-libs/lapack (upstream is > planning to add it). So we're stuck with LP64, unless we add USE=64bit- > index to sci-libs/lapack, for the more traditional ILP64 interface. Upstream is planning to add support for that. However, all things considered it's not a high priority -- it's just an implementation detail for us. > 3.2. The lazy approach > ---------------------- > The rough idea is that we move sci-libs/lapack away, via renaming > the libraries or moving them into a subdirectory, and put symlinks to > flexiblas in their place. Packages can continue searching for libblas, > liblapack, etc. as usual, and they will end up being linked to flexiblas > instead. > > Note that I haven't found time to test this yet, so I may be missing > some problem with it, but I can't think of one right now. What's > unclear to me is how we handle pkg-config files and CMake: if we also > replace them with symlinks to flexiblas ones, or leave as-is but with > the original paths that are now replaced by symlinks. I also need to > check if the CMake files installed by sci-libs/lapack are actually used > at all. > > Bad news is that it's less clean, and leaves us forever diverging in how > sci-libs/lapack is installed, and apps linking to '-lblas -lcblas > -llapack -llapacke' instead of '-lflexiblas'. I'm testing this for a while, and it's working quite well (modulo the xerbla_array_ problem mentioned). I haven't seen any problems from packages built before the switch (i.e. working via symlinks), nor built post the switch. Bad news is that it's a bit unidirectional. Once you switch to FlexiBLAS, the linker ends up linking to libflexiblas.so, and if you switch back, you have to rebuild stuff built with flexiblas (with preserved-libs, there is no immediate breakage). Technically, this could be solved by providing libblas.so, etc. wrappers instead of symlinks but I couldn't find a way to do that. I thought about copying what eselect-ldso does, but it turns out it's just horribly wrong (it duplicates all symbols) and shouldn't have ever been merged. One more reason to kill it with fire. I've created a tracker at: https://bugs.gentoo.org/963034 -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
