[gentoo-science] new blas infrastructure and prefix

[gentoo-science] new blas infrastructure and prefix

[fbissey]

Hi all,

So I was looking at the science overlay from my prefix on OS X.
And portage wanted me to upgrade my blas/cblas/lapack stack to the
new structure. I know they are marked ~x86 and ~amd64 but it doesn't
look good considering that I had a working stack in my prefix before.

So I may make things a little more prefix friendly (OS X in particular)
in the coming days. I am also thinking of adding an ebuild to use the
native vectorize framework on OS X, unless someone strongly objects to it.

Francois

Re: [gentoo-science] new blas infrastructure and prefix

[Johan Hattne]

On 30 Aug 2011, at 12:49, fbissey@slingshot.co.nz wrote:

> Hi all,
> 
> So I was looking at the science overlay from my prefix on OS X.
> And portage wanted me to upgrade my blas/cblas/lapack stack to the
> new structure. I know they are marked ~x86 and ~amd64 but it doesn't
> look good considering that I had a working stack in my prefix before.
> 
> So I may make things a little more prefix friendly (OS X in particular)
> in the coming days. I am also thinking of adding an ebuild to use the
> native vectorize framework on OS X, unless someone strongly objects to it.

Hi Francois;

With the CBLAS reference implementations, you may run into a problem with the test suite on Darwin.  I tried to sort this out earlier this year (see http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg00997.html), but I'm not even sure upstream recognises the problem.  Please let me know if at least you can reproduce the issue, and then maybe we can try again to get it fixed.

// Best wishes; Johan

Re: [gentoo-science] new blas infrastructure and prefix

[fbissey]

Quoting Johan Hattne <jhattne@lbl.gov>:

> On 30 Aug 2011, at 12:49, fbissey@slingshot.co.nz wrote:
>
>> Hi all,
>>
>> So I was looking at the science overlay from my prefix on OS X.
>> And portage wanted me to upgrade my blas/cblas/lapack stack to the
>> new structure. I know they are marked ~x86 and ~amd64 but it doesn't
>> look good considering that I had a working stack in my prefix before.
>>
>> So I may make things a little more prefix friendly (OS X in particular)
>> in the coming days. I am also thinking of adding an ebuild to use the
>> native vectorize framework on OS X, unless someone strongly objects to it.
>
> Hi Francois;
>
> With the CBLAS reference implementations, you may run into a problem 
> with the test suite on Darwin.  I tried to sort this out earlier this 
> year (see 
> http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg00997.html), 
> but I'm not even sure upstream recognises the problem.  Please let me 
> know if at least you can reproduce the issue, and then maybe we can 
> try again to get it fixed.
>
> // Best wishes; Johan
Thanks for the pointer. Right now that particular ebuild won't even install
because it assumes .so and linux.

First I want to solve the problem of eselect not listing stuff that is 
properly
installed. In particular gsl and blas-reference are installed properly, so are
their particular alternatives. Yet "eselect cblas list" and "eselect 
blas list"
return nothing. I think I have an idea of where the problem is. I just need a
bit of time to investigate.

Francois

Re: [gentoo-science] new blas infrastructure and prefix

[fbissey]

Quoting fbissey@slingshot.co.nz:
> First I want to solve the problem of eselect not listing stuff that is
> properly
> installed. In particular gsl and blas-reference are installed 
> properly, so are
> their particular alternatives. Yet "eselect cblas list" and "eselect
> blas list"
> return nothing. I think I have an idea of where the problem is. I just need a
> bit of time to investigate.
>
Found it! In alternatives.bash.in we have:
ALTERNATIVESDIR_ROOTLESS="@sysconfdir@/env.d/alternatives"
ALTERNATIVESDIR="${EROOT}${ALTERNATIVESDIR_ROOTLESS}"

EROOT is basically the prefix path, so the idea is you add
the prefix in the second line. Except that @sysconfigdir@
already include the prefix....
So instead of looking for alternatives in:
/Users/frb15/Desktop/Gentoo/etc/env.d/alternatives
it looked for them in:
/Users/frb15/Desktop/Gentoo/Users/frb15/Desktop/Gentoo/etc/env.d/alternatives

getting rid of one level of prefix in alternatives.bash got
me some working eselect for blas (reference), cblas (gsl) and lapack
(reference).

I'll leave bicatali to make the fix he deems appropriate.

Francois

Re: [gentoo-science] new blas infrastructure and prefix

[fbissey]

Quoting Johan Hattne <jhattne@lbl.gov>:

> On 30 Aug 2011, at 12:49, fbissey@slingshot.co.nz wrote:
>
>> Hi all,
>>
>> So I was looking at the science overlay from my prefix on OS X.
>> And portage wanted me to upgrade my blas/cblas/lapack stack to the
>> new structure. I know they are marked ~x86 and ~amd64 but it doesn't
>> look good considering that I had a working stack in my prefix before.
>>
>> So I may make things a little more prefix friendly (OS X in particular)
>> in the coming days. I am also thinking of adding an ebuild to use the
>> native vectorize framework on OS X, unless someone strongly objects to it.
>
> Hi Francois;
>
> With the CBLAS reference implementations, you may run into a problem 
> with the test suite on Darwin.  I tried to sort this out earlier this 
> year (see 
> http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg00997.html), 
> but I'm not even sure upstream recognises the problem.  Please let me 
> know if at least you can reproduce the issue, and then maybe we can 
> try again to get it fixed.
>
Looking at that thread they don't seem to see a problem. I haven't tackled
cblas-reference yet but I have made an ebuild to use the vectorize framework
from apple on OS X (I'll put it in the overlay soonish) and the test suite for
lapack-reference totaly failed when built with either blas-reference or
vectorize. I am guessing that it must be similar to what you got with
cblas-reference.

Francois

Re: [gentoo-science] new blas infrastructure and prefix

[Andrea Arteaga]

Hi Francois.
So, the package lapack-reference is emerged, but the test suite fails, right?
Could you just write a very basic C or Fortran program using a routine
of the LAPACK and compile it with the instruction of pkg-config
lapack, after having emerged lapack-reference and skipped the tests?

Cheers
Andrea

Re: [gentoo-science] new blas infrastructure and prefix

[fbissey]

Quoting Andrea Arteaga <andyspiros@gmail.com>:

> Hi Francois.
> So, the package lapack-reference is emerged, but the test suite fails, right?
> Could you just write a very basic C or Fortran program using a routine
> of the LAPACK and compile it with the instruction of pkg-config
> lapack, after having emerged lapack-reference and skipped the tests?
>
I will look into that. For the record, while I didn't run the test for 
the main
prefix tree version (ie not the science overlay) it worked fine as far 
as I can
tell - the sage testsuite runs a number of tests which depend on a working
lapack.

Francois

Re: [gentoo-science] new blas infrastructure and prefix

[fbissey]

Quoting Andrea Arteaga <andyspiros@gmail.com>:

> Hi Francois.
> So, the package lapack-reference is emerged, but the test suite fails, right?
> Could you just write a very basic C or Fortran program using a routine
> of the LAPACK and compile it with the instruction of pkg-config
> lapack, after having emerged lapack-reference and skipped the tests?
>
Probably would work. I had a close look at one of the test programs:

frb15@BlueFerniMac1
~/Desktop/Gentoo/var/tmp/portage/sci-libs/lapack-reference-3.3.1-r1/work/lapack-reference-3.3.1_build/bin
$ ./xeigtstc
dyld: Library not loaded: /Users/frb15/Desktop/Gentoo/usr/lib/libtmglib.dylib
   Referenced from:
/Users/frb15/Desktop/Gentoo/var/tmp/portage/sci-libs/lapack-reference-3.3.1-r1/work/lapack-reference-3.3.1_build/bin/./xeigtstc
   Reason: image not found
Trace/BPT trap
frb15@BlueFerniMac1
~/Desktop/Gentoo/var/tmp/portage/sci-libs/lapack-reference-3.3.1-r1/work/lapack-reference-3.3.1_build/bin
$ ls ../lib/
libreflapack.dylib  libtmglib.dylib

In short it is linked as if it was installed. So it doesn't find one of its
essential library. I am not quite sure how to fix this - in a general fashion.
I think I may be able to do something on OS X. It may actually be easier on a
linux prefix by using LD_LIBRARY_PATH. But the real solution would be for the
test run to have different linking options.

Francois

Re: [gentoo-science] new blas infrastructure and prefix

[fbissey]

Quoting fbissey@slingshot.co.nz:

> Hi all,
>
> So I was looking at the science overlay from my prefix on OS X.
> And portage wanted me to upgrade my blas/cblas/lapack stack to the
> new structure. I know they are marked ~x86 and ~amd64 but it doesn't
> look good considering that I had a working stack in my prefix before.
>
> So I may make things a little more prefix friendly (OS X in particular)
> in the coming days. I am also thinking of adding an ebuild to use the
> native vectorize framework on OS X, unless someone strongly objects to it.

Odd stuff, in the latest gsl from the science overlay someone decided not to
support linking with an external cblas anymore. For some reasons it breaks gsl
on OS X. I have no idea if it is also broken in the main tree if you use
internal gslcblas but I suspect it is. Using an external cblas however worked
fine as far as I can tell.

Francois

Re: [gentoo-science] new blas infrastructure and prefix

[fbissey]

Quoting fbissey@slingshot.co.nz:

> Quoting fbissey@slingshot.co.nz:
>
>> Hi all,
>>
>> So I was looking at the science overlay from my prefix on OS X.
>> And portage wanted me to upgrade my blas/cblas/lapack stack to the
>> new structure. I know they are marked ~x86 and ~amd64 but it doesn't
>> look good considering that I had a working stack in my prefix before.
>>
>> So I may make things a little more prefix friendly (OS X in particular)
>> in the coming days. I am also thinking of adding an ebuild to use the
>> native vectorize framework on OS X, unless someone strongly objects to it.
>
> Odd stuff, in the latest gsl from the science overlay someone decided not to
> support linking with an external cblas anymore. For some reasons it 
> breaks gsl
> on OS X. I have no idea if it is also broken in the main tree if you use
> internal gslcblas but I suspect it is. Using an external cblas however worked
> fine as far as I can tell.
>
I got that all wrong. I never had another cblas on OS X before. And I now see
that the external cblas option is gone from gsl itself. So why is it not
working anymore on OS X

[gentoo-science] new blas infrastructure on OS X prefix

[fbissey]

Hi,

I have to sadly report that currently the new blas infrastructure from the
science overlay is broken on at least OS X prefix. For example sage doesn't
start with the following message:
sage
----------------------------------------------------------------------
| Sage Version 4.7.2.alpha2, Release Date: 2011-08-24                |
| Type notebook() for the GUI, and license() for information.        |
----------------------------------------------------------------------
**********************************************************************
*                                                                    *
* Warning: this is a prerelease version, and it may be unstable.     *
*                                                                    *
**********************************************************************
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)

/Users/frb15/Desktop/Gentoo/usr/lib/python2.7/site-packages/IPython/ipmaker.pyc
in force_import(modname, force_reload)
      61         reload(sys.modules[modname])
      62     else:
---> 63         __import__(modname)
      64
      65

/Users/frb15/Desktop/Gentoo/usr/bin/ipy_profile_sage.py in ()
       5     preparser(True)
       6
----> 7     import sage.all_cmdline
       8     sage.all_cmdline._init_cmdline(globals())
       9

/Users/frb15/Desktop/Gentoo/usr/lib/python2.7/site-packages/sage/all_cmdline.py
in ()
      12 try:
      13
---> 14     from sage.all import *
      15     from sage.calculus.predefined import x
      16     preparser(on=True)

/Users/frb15/Desktop/Gentoo/usr/lib/python2.7/site-packages/sage/all.py in ()
      73 from time                import sleep
      74
---> 75 from sage.misc.all       import *         # takes a while
      76
      77 from sage.misc.sh import sh

/Users/frb15/Desktop/Gentoo/usr/lib/python2.7/site-packages/sage/misc/all.py 
in
()
      79 from func_persist import func_persist
      80
---> 81 from functional import (additive_order,
      82                         sqrt as numerical_sqrt,
      83                         arg,

/Users/frb15/Desktop/Gentoo/usr/lib/python2.7/site-packages/sage/misc/functional.py
in ()
      36
      37
---> 38 from sage.rings.complex_double import CDF
      39 from sage.rings.real_double import RDF, RealDoubleElement
      40

ImportError:
dlopen(/Users/frb15/Desktop/Gentoo/usr/lib/python2.7/site-packages/sage/rings/complex_double.bundle,
2): Symbol not found: _cblas_caxpy
   Referenced from: /Users/frb15/Desktop/Gentoo/usr/lib/libgsl.0.dylib
   Expected in: dynamic lookup

The key word is dynamic lookup. On OS X most library have an install_name that
is losely speaking similar to a rpath. Library declare their install_name and
the install_name of all the libraries they depend on. But you can use "dynamic
look up" to get the kind of behavior you would expect on linux. For 
some reason
switching to the new infrastructure break the dynamic look up of cblas 
for gsl,
and probably scipy and other. I don't know if it is limited to python 
extension
(in OS X speak bundles, on linux they appear as .so but in fact they may have
more in common with plugins).

I also don't know if it is broken on other prefix, I suspect linux 
prefixes are
OK.

Francois