Hi Michał, Michał Górny <[email protected]> writes:
> TL;DR: I'm proposing removing eselect-blas/lapack and the virtuals, > and using sci-libs/flexiblas instead. After reading the flexiblas related publications, I find it a cleaner solution to our eselect-ldso. > 1. The problem > ============== > The current Gentoo infrastructure for supporting multiple BLAS/LAPACK > variants doesn't really work. The primary problem is that while the > interfaces are standardized, they are also versioned and different > providers (and their different versions) tend to diverge over what's > implemented. On top of that, packages generally don't stop at a kind > of "common subset" (whatever that would be), but tend to detect which > routines are implemented by the BLAS/LAPACK libraries actually used. > The end result is that if you build a package against library A, then > it may or may not work with library B after switching. > > While I agree in principle with eselect-ldso being superior to regular > alternatives, it suffers from this problem even more. Since we're > building packages against sci-libs/lapack, i.e. the reference > implementation, we're effectively building against the most complete > implementation. > > Given the ABI problem, no solution based on alternatives or virtuals > can really work. > > > 2. Proposed solution > ==================== > I'd like to propose a two-tier replacement to the current system: > > 1. Base BLAS/LAPACK support via sci-libs/flexiblas. > > 2. USE flags for specific implementations for packages that use > additional functions beyond standard BLAS/LAPACK interfaces. > > [...] While I have not personally encountered the ABI incompatibilities described with my setups with blis and OpenBLAS, I found the analysis and proposed solution to be sound and well-reasoned. The proposed approach makes sense to me from a technical standpoint. Yours, Benda
signature.asc
Description: PGP signature
