On 01/12/12 15:27, Thomas Kahle wrote:
> On 12:06 Fri 02 Nov 2012, [email protected] wrote:
>> Quoting Thomas Kahle <[email protected]>:
>>
>>> On 09:42 Thu 01 Nov 2012, [email protected] wrote:
>>>> Quoting Thomas Kahle <[email protected]>:
>>>>
>>>>> 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
