Re: [gentoo-science] BLAS and LAPACK dependecy resolution

[Francois Bissey]

On 14/09/13 20:14, Markus Oehme wrote:
> Hi,
>
> At Thu, 12 Sep 2013 11:19:11 +0200,
> Markus wrote:
>> 4. remove /usr/lib/libblas.so (which was kept by preserve-libs)
>>    that is actually do 'rm /usr/lib/libblas.so'
>
>
> I see something really strange: repeatedly merging lapack-reference causes
> it to bounce between two states. Where in one state there are three
> additional files installed by the package:
> /usr/lib/debug/usr/lib64/libblas.so.debug
> /usr/lib64/libblas.so
> /usr/lib64/pkgconfig/blas.pc
> I tried it a larger number of times and the package alternates predictably
> between the two states. Any hints on how this can happen? Also it seems that
> in the state where the files are not there other packages have difficulties
> finding BLAS -- so the woes do not seem to be over yet. *sigh*
>
>
lapack-reference includes blas-reference. It looks to me that what
happens when you get these extra files is the following:
1) There is no blas properly eselected (or is broken)
2) because of (1) lapack-reference fails to find a blas at configure
time and therefore builds its own.
3) lapack-reference install libblas.so and related files.
At this stage in the cycle you merge lapack-reference again
1) while there is no blas properly eselected at configure stage the
previously installed libblas.so is found.
2) lapack-reference uses it to build libreflapack.so.
3) when lapack-reference is merged it doesn't include a libblas.so
and portage removes it when cleaning files from the previous merge.

Repeat....

So the solution is: properly eselect a blas and make sure it is a valid
and sane configuration.

I know this is annoying but after each time you merge a
blas/cblas/lapack and related friends which use altenatives, you need to
check
what is eselected.

Usually something valid is eselected but if you have several
implementations at the same time it tends to reset to the first one
in the list after each merge.

Francois