Comment # 6 on bug 1223967 from Atri Bhattacharya

(In reply to Egbert Eich from comment #5)
> On top of this, I believe I found a bug in /usr/lib/build/mkbaselibs which
> prevents 
>  liblapacke3
>    -/usr/lib(64)?/liblapacke.so.3
> to work correctly. This change would fix it:
>       } elsif (substr($r, 0, 1) eq '-') {
>         delete $files{$_} for grep {/$rr/} keys %files;
> +       delete $moves{$_} for grep {/$rr/} keys %moves;
>       } elsif (substr($r, 0, 1) eq '"') {
> 
> However, this is moot since baselibs is too limited anyway.
> 
> Of course, you could use _multibuild to create the entire set of libraries
> as v3 libs. %_libdir would have to point to /usr/lib64/hwcaps/x86-64-v3/ and
> you may want to append a '_v3' to the names of the blas, cblas, lapack and
> lapacke subdirectories where the 'real' versions of the libraries reside.
> Moreover, since this is for x86_64 only, you need to make sure to prevent
> the build of the v3 flavor on other arches.
> Of course, this will not make the spec file more readable.

Thanks Egbert, I will try to make this multibuild work. You can review it and
see how it looks and we can discard it if the specfile becomes too unwieldy.
Complex specfiles will turn off potential new contributors, but AVX/AVX2
enhanced lapack might be too good to miss out on... tricky balancing act.

Correct me if I am wrong, but the GCC `-march` I would use for the new flavour
is just `x86-64-v3`, right? That's it, no other additional flags?