| 1 |
Well .... |
| 2 |
|
| 3 |
I found that the link was wrong (old version) it was pointing to |
| 4 |
nowhere. I removed it. Now i have no link in /usr/lib{64} anymore: |
| 5 |
|
| 6 |
file /opt/acml5.3.1/gfortran64/lib/libacml.so |
| 7 |
/opt/acml5.3.1/gfortran64/lib/libacml.so: ELF 64-bit LSB shared object, |
| 8 |
x86-64, version 1 (SYSV), dynamically linked, not stripped |
| 9 |
|
| 10 |
pkg-config lapack --libs |
| 11 |
-L//opt/acml5.3.1/gfortran64/lib -lacml |
| 12 |
|
| 13 |
And yes eselect shows acml. |
| 14 |
|
| 15 |
|
| 16 |
Am 13.01.2014 23:58, schrieb François Bissey: |
| 17 |
> On 2014-01-14 11:49, Bastian Löffler wrote: |
| 18 |
>> Hi |
| 19 |
>> |
| 20 |
>> ls -la /usr/lib64/ | grep libacml.so |
| 21 |
>> lrwxrwxrwx 1 root root 40 19. Mai 2013 libacml.so -> |
| 22 |
>> /opt/acml5.3.0/gfortran64/lib/libacml.so |
| 23 |
>> |
| 24 |
>> It is from the science overlay it does not exist in the main tree: |
| 25 |
>> emerge -av acml |
| 26 |
>> |
| 27 |
>> These are the packages that would be merged, in order: |
| 28 |
>> |
| 29 |
>> Calculating dependencies... done! |
| 30 |
>> [ebuild Rf ] sci-libs/acml-5.3.1::science USE="doc examples |
| 31 |
>> gfortran openmp -fma -ifort -int64 -open64 -pgi -static-libs {-test}" |
| 32 |
>> 0 kB |
| 33 |
>> |
| 34 |
>> |
| 35 |
> OK I just find it bizarre that there is a link in /usr/lib64, I don't |
| 36 |
> have it installed |
| 37 |
> myself. So I am guessing |
| 38 |
> eselect blas list |
| 39 |
> will show acml as being selected and |
| 40 |
> eselect lapack list |
| 41 |
> will show the same. |
| 42 |
> Is |
| 43 |
> file /opt/acml5.3.0/gfortran64/lib/libacml.so |
| 44 |
> reporting a 64bit shared object as it should? |
| 45 |
> And finally what does |
| 46 |
> pkg-config lapack --libs |
| 47 |
> says? |
| 48 |
> |
| 49 |
> Francois |
| 50 |
> |
| 51 |
> |
Archives