Marc Vinyals | 1 Jun 17:48 2011

Re: sci-libs/scipy-0.9.0-r1 undefined symbol: clapack_sgesv

EL Wed, 1 Jun 2011 06:57:03 +1200
Francois Bissey <fbissey <at> slingshot.co.nz> escrigué:

> > Hi,
> > 
> > While updating sage and python to 4.7 and 2.7, I hit a variation of
> > an old bug (see http://bugs.gentoo.org/195619): scipy compiles with
> > lapack-reference but is unusable. Running in python
> > 
> > import scipy.optimize
> > 
> > fails with
> > 
> > [...]
> >     from scipy.linalg import clapack
> > ImportError: /usr/lib64/python2.7/site-packages/scipy/linalg/clapack.so:
> > undefined symbol: clapack_sgesv
> > 
> > I tried rebuilding numpy and scipy with lapack provided (eselect) by
> > lapack-reference, blas provided by blas-reference, cblas provided by
> > gsl and with/without clapack with the same result.
> > 
> > Then I tried rebuilding numpy and scipy with lapack, blas and cblas
> > provided (eselect) by atlas and scipy worked flawlessly.
> > 
> > Should scipy depend on a specific lapack provider instead of a
> > virtual? Enable it at compile time? Is it an unfortunate
> > combination what fails?
> > 
> > I can provide build logs if you need them.
(Continue reading)

Francois Bissey | 1 Jun 21:22 2011
Picon

Re: sci-libs/scipy-0.9.0-r1 undefined symbol: clapack_sgesv

> EL Wed, 1 Jun 2011 06:57:03 +1200
> 
> Francois Bissey <fbissey <at> slingshot.co.nz> escrigué:
> > > Hi,
> > > 
> > > While updating sage and python to 4.7 and 2.7, I hit a variation of
> > > an old bug (see http://bugs.gentoo.org/195619): scipy compiles with
> > > lapack-reference but is unusable. Running in python
> > > 
> > > import scipy.optimize
> > > 
> > > fails with
> > > 
> > > [...]
> > > 
> > >     from scipy.linalg import clapack
> > > 
> > > ImportError:
> > > /usr/lib64/python2.7/site-packages/scipy/linalg/clapack.so: undefined
> > > symbol: clapack_sgesv
> > > 
> > > I tried rebuilding numpy and scipy with lapack provided (eselect) by
> > > lapack-reference, blas provided by blas-reference, cblas provided by
> > > gsl and with/without clapack with the same result.
> > > 
> > > Then I tried rebuilding numpy and scipy with lapack, blas and cblas
> > > provided (eselect) by atlas and scipy worked flawlessly.
> > > 
> > > Should scipy depend on a specific lapack provider instead of a
> > > virtual? Enable it at compile time? Is it an unfortunate
(Continue reading)

Marc Vinyals | 2 Jun 12:32 2011

Re: sci-libs/scipy-0.9.0-r1 undefined symbol: clapack_sgesv

EL Thu, 2 Jun 2011 07:22:18 +1200
Francois Bissey <fbissey <at> slingshot.co.nz> escrigué:

> > EL Wed, 1 Jun 2011 06:57:03 +1200
> > 
> > Francois Bissey <fbissey <at> slingshot.co.nz> escrigué:
> > > > Hi,
> > > > 
> > > > While updating sage and python to 4.7 and 2.7, I hit a
> > > > variation of an old bug (see http://bugs.gentoo.org/195619):
> > > > scipy compiles with lapack-reference but is unusable. Running
> > > > in python
> > > > 
> > > > import scipy.optimize
> > > > 
> > > > fails with
> > > > 
> > > > [...]
> > > > 
> > > >     from scipy.linalg import clapack
> > > > 
> > > > ImportError:
> > > > /usr/lib64/python2.7/site-packages/scipy/linalg/clapack.so:
> > > > undefined symbol: clapack_sgesv
> > > > 
> > > > I tried rebuilding numpy and scipy with lapack provided
> > > > (eselect) by lapack-reference, blas provided by blas-reference,
> > > > cblas provided by gsl and with/without clapack with the same
> > > > result.
> > > > 
(Continue reading)

Francois Bissey | 4 Jun 02:15 2011
Picon

Re: sci-libs/scipy-0.9.0-r1 undefined symbol: clapack_sgesv

> Here are my logs. You'll find some warnings in the configuration
> stage, I hope they'll mean something to you. Also, there's no trace of
> libclapack.so in
> ldd /usr/lib64/python2.7/site-packages/scipy/linalg/clapack.so.

The output of ldd /usr/lib64/python2.7/site-packages/scipy/linalg/clapack.so
is very suspicious with Atlas it should look like this:
ldd /usr/lib/python2.7/site-packages/scipy/linalg/clapack.so
        linux-gate.so.1 =>  (0xb7890000)
        liblapack.so.0 => /usr/lib/liblapack.so.0 (0xb732a000)
        libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 (0xb71bb000)
        libc.so.6 => /lib/libc.so.6 (0xb7035000)
        libblas.so.0 => /usr/lib/blas/atlas/libblas.so.0 (0xb7014000)
        libcblas.so.0 => /usr/lib/blas/atlas/libcblas.so.0 (0xb6ff2000)
        libatlas.so.0 => /usr/lib/libatlas.so.0 (0xb6933000)
        libgfortran.so.3 => /usr/lib/gcc/i686-pc-linux-
gnu/4.5.2/libgfortran.so.3 (0xb6871000)
        libm.so.6 => /lib/libm.so.6 (0xb684b000)
        libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.5.2/libgcc_s.so.1 
(0xb682d000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb6813000)
        libdl.so.2 => /lib/libdl.so.2 (0xb680f000)
        libutil.so.1 => /lib/libutil.so.1 (0xb680b000)
        /lib/ld-linux.so.2 (0xb7891000)

So nothing from blas/cblas/lapack was linked into your scipy which is very 
worrying. It may be that there is a problem with your current blas&co setup.
what's the output of
ls -la /usr/lib64/libcblas.so

(Continue reading)

Marc Vinyals | 4 Jun 11:08 2011

Re: sci-libs/scipy-0.9.0-r1 undefined symbol: clapack_sgesv

EL Sat, 4 Jun 2011 12:15:18 +1200
Francois Bissey <fbissey <at> slingshot.co.nz> escrigué:

> > Here are my logs. You'll find some warnings in the configuration
> > stage, I hope they'll mean something to you. Also, there's no trace
> > of libclapack.so in
> > ldd /usr/lib64/python2.7/site-packages/scipy/linalg/clapack.so.
> 
> The output of
> ldd /usr/lib64/python2.7/site-packages/scipy/linalg/clapack.so is
> very suspicious with Atlas it should look like this:
> ldd /usr/lib/python2.7/site-packages/scipy/linalg/clapack.so
> linux-gate.so.1 =>  (0xb7890000) liblapack.so.0
> => /usr/lib/liblapack.so.0 (0xb732a000) libpython2.7.so.1.0
> => /usr/lib/libpython2.7.so.1.0 (0xb71bb000) libc.so.6
> => /lib/libc.so.6 (0xb7035000) libblas.so.0
> => /usr/lib/blas/atlas/libblas.so.0 (0xb7014000) libcblas.so.0
> => /usr/lib/blas/atlas/libcblas.so.0 (0xb6ff2000) libatlas.so.0
> => /usr/lib/libatlas.so.0 (0xb6933000) libgfortran.so.3
> => /usr/lib/gcc/i686-pc-linux- gnu/4.5.2/libgfortran.so.3 (0xb6871000)
>         libm.so.6 => /lib/libm.so.6 (0xb684b000)
>         libgcc_s.so.1
> => /usr/lib/gcc/i686-pc-linux-gnu/4.5.2/libgcc_s.so.1 (0xb682d000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0xb6813000)
>         libdl.so.2 => /lib/libdl.so.2 (0xb680f000)
>         libutil.so.1 => /lib/libutil.so.1 (0xb680b000)
>         /lib/ld-linux.so.2 (0xb7891000)
> 
> So nothing from blas/cblas/lapack was linked into your scipy which is
> very worrying. It may be that there is a problem with your current
(Continue reading)

P Purkayastha | 5 Jun 11:48 2011
Picon

[patch] system-wide install of debug_gap.vim can not be overridden

Hi,

   I installed sage and also gap via the sage-for-gentoo overlay on a 
Gentoo linux system (64 bit installation). It turned out that gap 
installed a plugin /usr/share/vim/vimfiles/plugin/gap_debug.vim where 
some keybindings are defined to help debug gap programs.

First, I think this file should go under 
/usr/share/vim/vimfiles/ftplugin directory since it applies only to gap 
files. Secondly, the files define some keybindings without allowing for 
the user to override those keybindings in ~/.vimrc.

I am attaching a patch which defines a global vim variable. If the user 
sets that variable in ~/.vimrc, then this gap plugin will not be read. 
This is one way I think the plugin can be made to not supersede user 
settings.

If there is some other way of overriding that plugin file, please let me 
know.

    Thanks and regards,
      Punarbasu.
--- debug_gap.vim	2011-06-05 17:29:33.473985132 +0800
+++ debug_gap.vim.new	2011-06-05 17:35:51.686985062 +0800
 <at>  <at>  -6,6 +6,12  <at>  <at> 
 "
 " $Id: debug.vim,v 1.1 2003/04/07 17:06:17 gap Exp $
 "
(Continue reading)

Francois Bissey | 6 Jun 21:18 2011
Picon

Re: [patch] system-wide install of debug_gap.vim can not be overridden

> Hi,
> 
>    I installed sage and also gap via the sage-for-gentoo overlay on a
> Gentoo linux system (64 bit installation). It turned out that gap
> installed a plugin /usr/share/vim/vimfiles/plugin/gap_debug.vim where
> some keybindings are defined to help debug gap programs.
> 
> First, I think this file should go under
> /usr/share/vim/vimfiles/ftplugin directory since it applies only to gap
> files. Secondly, the files define some keybindings without allowing for
> the user to override those keybindings in ~/.vimrc.
> 
> I am attaching a patch which defines a global vim variable. If the user
> sets that variable in ~/.vimrc, then this gap plugin will not be read.
> This is one way I think the plugin can be made to not supersede user
> settings.
> 
> If there is some other way of overriding that plugin file, please let me
> know.
> 
Hi,

thanks for the info. It looks like you have found something that is installed
by "automagic". Not being a fan of vi I don't have it installed and that vim
file is not installed here. We may need to put it under useflag control.
I think we may adopt your patch until someone more knowledgeable in vim
tell us that's the wrong way of doing things.

Francois

(Continue reading)

Francois Bissey | 6 Jun 21:33 2011
Picon

Re: sci-libs/scipy-0.9.0-r1 undefined symbol: clapack_sgesv

> EL Sat, 4 Jun 2011 12:15:18 +1200
> 
> ls -la /usr/lib64/libcblas.so
> lrwxrwxrwx 1 root root 26  2 jun 13:44 /usr/lib64/libcblas.so ->
> blas/reference/libcblas.so
> 
> ls -la /usr/lib64/libblas.so
> lrwxrwxrwx 1 root root 25  2 jun 13:43 /usr/lib64/libblas.so ->
> blas/reference/libblas.so
> 
> ls -la /usr/lib64/liblapack.so
> lrwxrwxrwx 1 root root 29  2 jun 13:47 /usr/lib64/liblapack.so ->
> lapack/reference/liblapack.so
> 
> It looks reasonable to me.
It does. Yet your scipy doesn't link to anything blas related according
to the output of ldd that you sent. 
I note you are using numpy-1.6.0 I don't if that's linked to that but sage
will not work properly with it: 
http://trac.sagemath.org/sage_trac/ticket/11334
Can you try again with numpy-1.5.1 at least.
And then what are the outputs of:
ldd /usr/lib64/python2.7/site-packages/numpy/core/_dotblas.so
ldd /usr/lib64/python2.7/site-packages/numpy/linalg/lapack_lite.so

Francois

Marc Vinyals | 6 Jun 23:20 2011

Re: sci-libs/scipy-0.9.0-r1 undefined symbol: clapack_sgesv

EL Tue, 7 Jun 2011 07:33:27 +1200
Francois Bissey <fbissey <at> slingshot.co.nz> escrigué:

> I note you are using numpy-1.6.0 I don't if that's linked to that but
> sage will not work properly with it: 
> http://trac.sagemath.org/sage_trac/ticket/11334
> Can you try again with numpy-1.5.1 at least.

I am a bit surprised, but downgrading numpy actually worked. Thanks a
lot for your help, Francois! Sage-4.7 should depend on ~numpy-1.5.1
then, since it already depends on >=numpy-1.5.1.

> And then what are the outputs of:
> ldd /usr/lib64/python2.7/site-packages/numpy/core/_dotblas.so
> ldd /usr/lib64/python2.7/site-packages/numpy/linalg/lapack_lite.so

They link to lapack, blas and cblas, and they didn't change when I
downgraded numpy.
P Purkayastha | 7 Jun 06:19 2011
Picon

Re: [patch] system-wide install of debug_gap.vim can not be overridden

On Tue, 07 Jun 2011 03:18:51 +0800, Francois Bissey  
<fbissey <at> slingshot.co.nz> wrote:

>> Hi,
>>
>>    I installed sage and also gap via the sage-for-gentoo overlay on a
>> Gentoo linux system (64 bit installation). It turned out that gap
>> installed a plugin /usr/share/vim/vimfiles/plugin/gap_debug.vim where
>> some keybindings are defined to help debug gap programs.
>>
>> First, I think this file should go under
>> /usr/share/vim/vimfiles/ftplugin directory since it applies only to gap
>> files. Secondly, the files define some keybindings without allowing for
>> the user to override those keybindings in ~/.vimrc.
>>
>> I am attaching a patch which defines a global vim variable. If the user
>> sets that variable in ~/.vimrc, then this gap plugin will not be read.
>> This is one way I think the plugin can be made to not supersede user
>> settings.
>>
>> If there is some other way of overriding that plugin file, please let me
>> know.
>>
> Hi,
>
> thanks for the info. It looks like you have found something that is  
> installed
> by "automagic". Not being a fan of vi I don't have it installed and that  
> vim
> file is not installed here. We may need to put it under useflag control.
(Continue reading)


Gmane