1 |
On 01/12/12 15:27, Thomas Kahle wrote: |
2 |
> On 12:06 Fri 02 Nov 2012, fbissey@××××××××××××.nz wrote: |
3 |
>> Quoting Thomas Kahle <tomka@g.o>: |
4 |
>> |
5 |
>>> On 09:42 Thu 01 Nov 2012, fbissey@××××××××××××.nz wrote: |
6 |
>>>> Quoting Thomas Kahle <tomka@g.o>: |
7 |
>>>> |
8 |
>>>>> One more thing, This is fixed in 1.6 tree of numpy, where the |
9 |
>>>>> call to gfortran uses what is in the site config. |
10 |
>>>>> Will sage move to a higher version of numpy at some point? |
11 |
>>>>> |
12 |
>>>>> |
13 |
>>>> Yes! The problem that prevent us to upgrade numpy is fixed in numpy-1.7. The |
14 |
>>>> release cannot come quickly enough for us. |
15 |
>>> |
16 |
>>> OK. Any idea when this will happen? |
17 |
>>> |
18 |
>>>> For numpy 1.5 would by any chance gfortran be called with -fexternal-blas at |
19 |
>>>> some point? |
20 |
>>> |
21 |
>>> Can't find '-fexternal' in build.log. |
22 |
>>> |
23 |
>>>> On my system with python 3.2 lapack was not properly detected, |
24 |
>>>> that's why dotblas hasn't been built. Numpy 1.5.1 with python 3.2 used an |
25 |
>>>> internal implementation of the lapack functions it uses. |
26 |
>>>> |
27 |
>>>> This probably explains why scipy doesn't compile with numpy 1.5 and |
28 |
>>>> python 3.2. |
29 |
>>> |
30 |
>>> And this where all this started for me ... |
31 |
>>> |
32 |
>>> Anyway, the solution of my broken numpy,scipy is to wait for 1.7 or |
33 |
>>> rollback to a reference-lapack that installs itself as liblapack? |
34 |
>>> |
35 |
>> |
36 |
>> If you don't use numpy with python 3.x you could simply create a file |
37 |
>> /etc/portage/env/dev-python/numpy with USE_PYTHON="2.7" in it. |
38 |
>> That would skip the offending problem quite nicely without locking you |
39 |
>> in a particular blas implementation. |
40 |
> |
41 |
> Do you have a reference for your method? It does not work for me. |
42 |
> Instead in /etc/portage/env/ I have a file nopy3k.conf which contains |
43 |
> just USE_PYTHON="2.7". Then in /etc/portage/package.env I configure |
44 |
> |
45 |
> dev-python/numpy nopy3k.conf |
46 |
> |
47 |
|
48 |
I suppose that your way is newer, I have been using mine for a *number* |
49 |
of years. From "man portage": |
50 |
/etc/portage/env/ |
51 |
In this directory additional package-specific bashrc files can be |
52 |
created. Note that if package-specific environment variable |
53 |
settings are all that's needed, then /etc/portage/package.env should |
54 |
be used instead of the bashrc approach that is described here. Also note |
55 |
that special variables such as FEATURES and INSTALL_MASK will |
56 |
not produce the intended results if they are set in bashrc, and |
57 |
therefore /etc/portage/package.env should be used instead. |
58 |
|
59 |
Portage will source all of these bashrc files after |
60 |
/etc/portage/bashrc in the following order: |
61 |
1. /etc/portage/env/${CATEGORY}/${PN} |
62 |
2. /etc/portage/env/${CATEGORY}/${PN}:${SLOT} |
63 |
3. /etc/portage/env/${CATEGORY}/${P} |
64 |
4. /etc/portage/env/${CATEGORY}/${PF} |
65 |
|
66 |
So technically it should work. It has a defect that probably makes the |
67 |
package.env approach extremely preferable as I found out. Variables set |
68 |
with this method (/etc/portage/env/${CATEGORY}/${PN}) will override |
69 |
variables you pass on the shell. I found that the hard way. |
70 |
|
71 |
Of course with the new python eclass some adjustment will be needed. |
72 |
|
73 |
|
74 |
Francois |