1 |
Quoting Thomas Kahle <tomka@g.o>: |
2 |
|
3 |
> On 09:42 Thu 01 Nov 2012, fbissey@××××××××××××.nz wrote: |
4 |
>> Quoting Thomas Kahle <tomka@g.o>: |
5 |
>> |
6 |
>> > One more thing, This is fixed in 1.6 tree of numpy, where the |
7 |
>> > call to gfortran uses what is in the site config. |
8 |
>> > Will sage move to a higher version of numpy at some point? |
9 |
>> > |
10 |
>> > |
11 |
>> Yes! The problem that prevent us to upgrade numpy is fixed in numpy-1.7. The |
12 |
>> release cannot come quickly enough for us. |
13 |
> |
14 |
> OK. Any idea when this will happen? |
15 |
> |
16 |
>> For numpy 1.5 would by any chance gfortran be called with -fexternal-blas at |
17 |
>> some point? |
18 |
> |
19 |
> Can't find '-fexternal' in build.log. |
20 |
> |
21 |
>> On my system with python 3.2 lapack was not properly detected, |
22 |
>> that's why dotblas hasn't been built. Numpy 1.5.1 with python 3.2 used an |
23 |
>> internal implementation of the lapack functions it uses. |
24 |
>> |
25 |
>> This probably explains why scipy doesn't compile with numpy 1.5 and |
26 |
>> python 3.2. |
27 |
> |
28 |
> And this where all this started for me ... |
29 |
> |
30 |
> Anyway, the solution of my broken numpy,scipy is to wait for 1.7 or |
31 |
> rollback to a reference-lapack that installs itself as liblapack? |
32 |
> |
33 |
|
34 |
If you don't use numpy with python 3.x you could simply create a file |
35 |
/etc/portage/env/dev-python/numpy with USE_PYTHON="2.7" in it. |
36 |
That would skip the offending problem quite nicely without locking you |
37 |
in a particular blas implementation. |
38 |
|
39 |
Francois |