Re: [gentoo-science] Fwd: sci-lib/atlas, static libraries, cblas, lapack

[jody]

Hi
I think i begin to see how things have to work....
Just to make sure i understood correctly:
- the directories /usr/lib64/blas/reference/ and
/usr/lib64/lapack/reference/ and the libraries they contained are
irrelevant for the science overlay
- generally one compiles an application using cblas  with `pkg-config
--cflags cblas` and links it with `pkg-config --libs cblas` (and similarly
for blas and lapack)
Is this correct?

Thank You
  Jody


On Tue, Sep 3, 2013 at 11:57 AM, jody <jody.xha@×××××.com> wrote:

> Hi Francois
> Thanks for your reply.
>
> I already had eselect from the science overlay: version 1.3.7-r100[1] ([1]
> refers to the science overlay)
> and eselect-blas, eselect-cblas and eselect-lapack were already removed (i
> had to do this to emerge atlas).
>
> Now I unmasked and emerged the virtuals cblas, blas and lapack from the
> science overlay.
>
> when i look at the lib64 directory, i see
> aim-octopus ~ # ls -l /usr/lib64/liblapack.*
> lrwxrwxrwx 1 root root 28 Aug 20 09:43 /usr/lib64/liblapack.a ->
> lapack/reference/liblapack.a
> lrwxrwxrwx 1 root root 29 Aug 20 09:43 /usr/lib64/liblapack.so ->
> lapack/reference/liblapack.so
> lrwxrwxrwx 1 root root 31 Aug 20 09:43 /usr/lib64/liblapack.so.0 ->
> lapack/reference/liblapack.so.0
> aim-octopus ~ # ls -l /usr/lib64/libcblas.*
>
> lrwxrwxrwx 1 root root 13 Aug 20 10:54 /usr/lib64/libcblas.a ->
> libgslcblas.a
> lrwxrwxrwx 1 root root 14 Aug 20 10:54 /usr/lib64/libcblas.so ->
> libgslcblas.so
> lrwxrwxrwx 1 root root 16 Aug 20 10:54 /usr/lib64/libcblas.so.0 ->
> libgslcblas.so.0
> aim-octopus ~ # ls -l /usr/lib64/libblas.*
> lrwxrwxrwx 1 root root 24 Aug 19 18:07 /usr/lib64/libblas.a ->
> blas/reference/libblas.a
> lrwxrwxrwx 1 root root 25 Aug 19 18:07 /usr/lib64/libblas.so ->
> blas/reference/libblas.so
> lrwxrwxrwx 1 root root 27 Aug 19 18:07 /usr/lib64/libblas.so.0 ->
> blas/reference/libblas.so.0
>
> I found .pc files in /usr/lib64/blas/reference/ and
> /usr/lib64/lapack/reference/ but there is no directory
> /usr/lib64/cblas/reference. How can i get the cblas from the science
> overlay?
>
> I noticed that i have sci-libs/*-reference for blas and lapack emerged
> (even though none of them are from the science overlay) but no
> sci-libs/cblas-reference:
> aim-octopus ~ # eix blas-reference
> [I] sci-libs/blas-reference
>      Available versions:  20070226 ~20070226-r2 **20070226-r3 ~20120925[1]
> **99999999[1] {{doc static-libs test}}
>      Installed versions:  20070226(18:07:30 08/19/13)(-doc)
>      Homepage:            http://www.netlib.org/lapack/
>      Description:         Reference implementation of BLAS
>
> aim-octopus ~ # eix lapack-reference
> [I] sci-libs/lapack-reference
>      Available versions:  3.1.1-r1 ~3.2.1-r1 **3.2.1-r3 ~3.4.2[1]
> **9999[1] {{doc static-libs test xblas}}
>      Installed versions:  3.1.1-r1(09:43:40 08/20/13)(-doc)
>      Homepage:            http://www.netlib.org/lapack/
>      Description:         Reference implementation of LAPACK
>
> [1] "science" /var/lib/layman/science
>
> aim-octopus ~ # eix cblas-reference
> * sci-libs/cblas-reference
>      Available versions:  20030223-r4 ~20030223-r5 ~20110218[1]
> {{static-libs}}
>      Homepage:            http://www.netlib.org/blas/
>      Description:         C wrapper interface to the F77 reference BLAS
> implementation
>
> [1] "science" /var/lib/layman/science
>
>
> Do i need to emerge sci-libs/cblas-reference?
> Do i need to unmask and emerge the overlay versions for all
> sci-libs/*-reference as well?
>
>
> I am sorry, but i don't understand what you said about the .pc files.
> In what situation and how should i use the .pc file?
>
> Thanks
>   Jody
>
>
>
> On Tue, Sep 3, 2013 at 12:57 AM, François Bissey <fbissey@××××××××××××.nz>wrote:
>
>> Hi Jody,
>>
>> The mechanism for handling multiple BLAS/LAPACK in the science overlay
>> is incompatible with the one used in the main tree.
>> In particular the science overlay stack doesn't create link link to
>> libcblas,
>> libblas and liblapack.
>> You have to unmask eselect from the science overlay as well as the
>> virtuals
>> (cblas,blas and lapack) and remove all the tree eselect-blas,
>> eselect-cblas
>> and eselect-lapack modules.
>> No packages in Gentoo, in the tree or the overlay, should use libblas,
>> libcblas or
>> liblapack directly but configure it throught pkg-config.
>> All BLAS/LAPACK implementation in Gentoo provide .pc file for that
>> purpose. With
>> the new science overlay structure you create a link for which .pc file is
>> the default.
>>
>> So once you have completed your move to the science overlay stack you
>> need to remove
>> those links if they still exist.
>>
>> Francois
>>
>>
>> On 2013-09-02 19:04, jody wrote:
>>
>>> Hi
>>> I have successfully installed sci-libs/atlas from the science overlay.
>>>
>>> Now there are some points which are somewhat unclear.
>>>
>>> I have been redirected here from the gentoo forum.
>>>
>>>  1. cblas implementation
>>>  Even though
>>>
>>>  # eselect cblas list
>>>  Available providers for cblas:
>>>    [1]   atlas *
>>>    [2]   atlas-threads
>>>
>>>  all cblas libraries are pointing to gsl implementations:
>>>
>>>  ls -l /usr/lib64/libcblas.*
>>>  lrwxrwxrwx 1 root root 13 Aug 20 10:54 /usr/lib64/libcblas.a ->
>>> libgslcblas.a
>>>  lrwxrwxrwx 1 root root 14 Aug 20 10:54 /usr/lib64/libcblas.so ->
>>> libgslcblas.so
>>>  lrwxrwxrwx 1 root root 16 Aug 20 10:54 /usr/lib64/libcblas.so.0 ->
>>> libgslcblas.so.0
>>>
>>>  Shouldn't the '/usr/lib64/libcblas.so' point to
>>> '/usr/lib64/libatlcblas.so' etc.?
>>>
>>>  2. static libs for cblas
>>>  The installation of sci-libs/atlas did not create any static libs:
>>>
>>>  ls -l /usr/lib64/libatl*
>>>  lrwxrwxrwx 1 root root      13 Aug 22 09:11 /usr/lib64/libatlas.so
>>> -> libatlas.so.3
>>>  -rwxr-xr-x 1 root root 5961968 Aug 22 09:11 /usr/lib64/libatlas.so.3
>>>  lrwxrwxrwx 1 root root      16 Aug 22 09:11
>>> /usr/lib64/libatlcblas.so -> libatlcblas.so.3
>>>  -rwxr-xr-x 1 root root  142504 Aug 22 09:11
>>> /usr/lib64/libatlcblas.so.3
>>>
>>>  And i have at least one 3rd party code which requires the cblas
>>> libraries to be linked statically.
>>>
>>>  3. eselect lapack
>>>  I found that 'app-admin/eselect-lapack' is blocking 'sci-libs/atlas',
>>>
>>>  but atlas did not pull in eselect for lapack:
>>>
>>>   # eselect lapack list
>>>  !!! Error: Can't load module lapack
>>>  exiting
>>>
>>> eselect-cblas is also blocking 'sci-libs/atlas', but apparently atlas
>>> pulls in eselect for cblas.
>>>
>>> 4. Shouldn't there also be a lapack implementation from atlas?
>>>
>>>  Could somebody clarify or help out?
>>>  Jody
>>>
>>
>>
>