https://bugzilla.suse.com/show_bug.cgi?id=1223967 https://bugzilla.suse.com/show_bug.cgi?id=1223967#c4 --- Comment #4 from Atri Bhattacharya <badshah400@gmail.com> --- (In reply to Richard Biener from comment #3)
Hmm, but the dynamic loader relies on the shared library to be present in /usr/lib64/hwcaps/x86-64-v3/ (IIRC). So to work the alternatives link would need to be present there, pointing to the actual hwcaps library in /usr/lib64/blas/hwcaps/x86-64-v3/... (or another directory or a changed library name).
So I don't see how the generic hwcaps mechanism can be made work for the case of lapack. To me it seems the library copying would need to be done manually in lapack and only the multibuild part of the hwcaps mechanism preserved?
I see, thanks for the explanation.
That said, IMO having "alternatives" for shared libraries is a red herring... (but yeah, I understand why we have it, but then there's nothing wrong with Conflicts and multiple providers of liblapack.so.3)
Alternatively, is there a way to directly generate the -v3 tuned libs using a multibuild flavour specifically for this? I mean, we could give using the right flags to generate the v3 libs, move them to the appropriate location and package them as part of a package manually named to liblapack-x86_64-v3 or similar. However, I do not know what the macro does in step-by-step detail. -- You are receiving this mail because: You are on the CC list for the bug.