Re: [gentoo-science] is numpy using the old lapack interface?

[Francois Bissey]

On 01/12/12 15:27, Thomas Kahle wrote:
> On 12:06 Fri 02 Nov 2012, fbissey@××××××××××××.nz wrote:
>> Quoting Thomas Kahle <tomka@g.o>:
>>
>>> On 09:42 Thu 01 Nov 2012, fbissey@××××××××××××.nz wrote:
>>>> Quoting Thomas Kahle <tomka@g.o>:
>>>>
>>>>> One more thing, This is fixed in 1.6 tree of numpy, where the
>>>>> call to gfortran uses what is in the site config.
>>>>> Will sage move to a higher version of numpy at some point?
>>>>>
>>>>>
>>>> Yes! The problem that prevent us to upgrade numpy is fixed in numpy-1.7. The
>>>> release cannot come quickly enough for us.
>>>
>>> OK.  Any idea when this will happen?
>>>
>>>> For numpy 1.5 would by any chance gfortran be called with -fexternal-blas at
>>>> some point?
>>>
>>> Can't find '-fexternal' in build.log.
>>>
>>>> On my system with python 3.2 lapack was not properly detected,
>>>> that's why dotblas hasn't been built. Numpy 1.5.1 with python 3.2 used an
>>>> internal implementation of the lapack functions it uses.
>>>>
>>>> This probably explains why scipy doesn't compile with numpy 1.5 and
>>>> python 3.2.
>>>
>>> And this where all this started for me ...
>>>
>>> Anyway, the solution of my broken numpy,scipy is to wait for 1.7 or
>>> rollback to a reference-lapack that installs itself as liblapack?
>>>
>>
>> If you don't use numpy with python 3.x you could simply create a file
>> /etc/portage/env/dev-python/numpy with USE_PYTHON="2.7" in it.
>> That would skip the offending problem quite nicely without locking you
>> in a particular blas implementation.
>
> Do you have a reference for your method?  It does not work for me.
> Instead in /etc/portage/env/ I have a file nopy3k.conf which contains
> just USE_PYTHON="2.7".  Then in /etc/portage/package.env I configure
>
> dev-python/numpy nopy3k.conf
>

I suppose that your way is newer, I have been using mine for a *number*
of years. From "man portage":
/etc/portage/env/
    In this directory additional package-specific bashrc files can   be
created.  Note that if  package-specific  environment  variable
settings  are  all  that's needed, then /etc/portage/package.env should
be used instead of the bashrc approach that is described here. Also note
that special variables such as FEATURES and  INSTALL_MASK  will
not produce the intended results if they are set in bashrc, and
therefore /etc/portage/package.env should be used instead.

    Portage will source all of these bashrc files after
/etc/portage/bashrc in the following order:
              1. /etc/portage/env/${CATEGORY}/${PN}
              2. /etc/portage/env/${CATEGORY}/${PN}:${SLOT}
              3. /etc/portage/env/${CATEGORY}/${P}
              4. /etc/portage/env/${CATEGORY}/${PF}

So technically it should work. It has a defect that probably makes the
package.env approach extremely preferable as I found out. Variables set
with this method (/etc/portage/env/${CATEGORY}/${PN}) will override
variables you pass on the shell. I found that the hard way.

Of course with the new python eclass some adjustment will be needed.


Francois