Comment # 4 on bug 1223967 from Atri Bhattacharya

(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.