I don’t think your situation is possible without mixing stuff
from the main tree (blas) and the science overlay. I didn’t even
realise you could mix, but I don’t think that is sane.
gsl from the science overlay is unfortunately not in a good shape
and I don’t recommend to use it as cblas.

Unless there are particular reasons for not doing so, I would recommend
that you use openblas from the science overlay for both blas and cblas.
The following useflags for openblas are sane:
“int64 threads -openmp”
You’ll want to re-emerge lapack-reference once openblas is eselected.
For sanity.

François

> On 18/10/2016, at 20:43, v...@ukr.net wrote:
> 
> On Tue, 18 Oct 2016 09:11:59 +1300
> François Bissey <frp.bis...@gmail.com> wrote:
> 
>> ... If you have
>> "-lreflapack" what blas are you using if not "refblas"?
>> So does /usr/lib64/libgslcblas.so exist on your system?
>> Is /usr/lib64/libblas.so a dangling symlink (point to nothing)?
>> 
> Here is the output:
> 
> $ eselect blas list
> Available providers for blas:
>  [1]   reference *
> 
> $ ls -l /usr/lib64/libgslcblas.so
> lrwxrwxrwx 1 root root 20 бер 28  2016 /usr/lib64/libgslcblas.so -> 
> libgslcblas.so.0.0.0
> $ ls -l /usr/lib64/libgslcblas.so.0.0.0 
> -rwxr-xr-x 1 root root 251720 бер 28  2016 /usr/lib64/libgslcblas.so.0.0.0
> 
> $ ls -l /usr/lib64/libblas.so
> lrwxrwxrwx 1 root root 12 гру 15  2015 /usr/lib64/libblas.so -> libblas.so.3
> $ ls -l /usr/lib64/libblas.so.3
> lrwxrwxrwx 1 root root 16 гру 15  2015 /usr/lib64/libblas.so.3 -> 
> libblas.so.3.6.0
> $ ls -l /usr/lib64/libblas.so.3.6.0 
> -rwxr-xr-x 1 root root 362384 гру 15  2015 /usr/lib64/libblas.so.3.6.0
> 
> 
> So both files do exist.
> As of the GSL, it looks like on my system it is installed from 'science' 
> overlay:
> 
> $ emerge -vp gsl
> [ebuild   R    ] sci-libs/gsl-2.1:0/19::science  USE="-cblas-external -int64 
> -static-libs" ABI_X86="(64) -32" 0 KiB
> 
> Should I install the GSL from the main Portage tree instead?
>  Vladimir
> ----- 
> <v...@ukr.net>
> 


Reply via email to