I did not try the binaries yet, but I had built the version 2.8.1 from
sources, and this issue did not show up You might want to follow
the modifs in the distutils then.
best,
Johann
On Jan 6, 11:56 am, Joshua Kantor <[EMAIL PROTECTED]> wrote:
> Ok. I'm going to have to trace through the nump
Ok. I'm going to have to trace through the numpy distutils to try to
track down where that is exactly generated to get a better idea why
its showing up,
that will take some time.
The binaries work for you right?
On Jan 6, 7:01 am, Johannct <[EMAIL PROTECTED]> wrote:
> hello,
> I downloaded 2.92,
hello,
I downloaded 2.92, replaced the numpy spkg by the one provided by
joshua, undet SAGE_FORTRAN, and issued make, but I still have the same
issue :
building extension "numpy.core.multiarray" sources
Generating build/src.linux-i686-2.5/numpy/core/config.h
error: don't know how to compile Fortra
and what about the (linux2,gfortran) pair that I tried to force and
that still does not seem to be accepted?
best,
Johann
On Jan 4, 2:57 pm, Joshua Kantor <[EMAIL PROTECTED]> wrote:
> Well, that still doesn't explain anythinig as I get the same output
> for sys.platform and sys.name.
>
> Neverthe
strange... I just tried in the cluster of machines at work, where I
have a different shell environment, and have access to RHEL3 and 4
machines, and they all result in os.name returning posix and
sys.platform returning linux2
I will try your spkg today if I have still time, or tomorrow.
best,
Well, that still doesn't explain anythinig as I get the same output
for sys.platform and sys.name.
Nevertheless, I may know how to fix your problem even though I don't
know why its happening.
Try to put this spkg
http://sage.math.washington.edu/home/jkantor/spkgs/numpy-20071120-1.0.3.1.p3.spkg
hi Josh, here it is :
Sage subshell$ pwd
/data1/sources/sage-2.9.1.1/spkg/build/numpy-20071020-1.0.3.1.p3/src
Sage subshell$ cd ../../../../
Sage subshell$ ls
COPYING.txt data example.sage install.log ipython local
makefile matplotlibrc README.txt sage sage-2.9.1.txt sage-python
spkg t
some more debugging : I put printouts to 2 calls in fcompiler/
__init__.py, at the beginning of new_fcompiler and
_find_existing_fcomplers. The full screen output is copied below.
Several comments :
1) these methods seem to be called several times, not always with the
same arguments. In order :
CA
some more debugging : I put printouts to 2 calls in fcompiler/
__init__.py, at the beginning of new_fcompiler and
_find_existing_fcomplers. The full screen output is copied below.
Several comments :
1) these methods seem to be called several times, not always with the
same arguments. In order :
CA
Another thought. Please go into sage-2.9*/local/bin and
do
./python
to start the local python
what does
import sys
sys.platform
output.
(it should be something like linux2, but I wonder if it might come out
posix for you)
Josh
On Jan 4, 1:22 pm, mabshoff <[EMAIL PROTECTED]
dortmund.de> w
ok, I am doing a little debugging : the numpy error message comes from
numpy/distutils/fcompiler/__init__.py in the new_fcompiler function.
This function seems to be called with plat=None and compiler=gfortran.
As plat=None, the first thing that this method function does is
plat=os.name I chec
On Jan 4, 10:14 pm, Johannct <[EMAIL PROTECTED]> wrote:
Hi,
> hello,
> having root priviledge I went ahead and did : ln -s /usr/lib/
> libgfortran.so.1 /usr/lib/libgfortran.so
> It fixes the problem in the sense that I am now back to square one,
> with the initial numpy build failure :
Ok, but
hello,
having root priviledge I went ahead and did : ln -s /usr/lib/
libgfortran.so.1 /usr/lib/libgfortran.so
It fixes the problem in the sense that I am now back to square one,
with the initial numpy build failure :
running install
running build
running config_cc
unifing config_cc, config, build
On Jan 4, 9:52 pm, Johannct <[EMAIL PROTECTED]> wrote:
> fresh rebuild from a vanilla source, LD_LIBRARY_PATH, PYTHONPATH
> etc... unsetenved, and using make and *not* make -j2 and using
> SAGE_FORTRAN set to gfortran, I still stumble :
>
> make[3]: `libcblas.so' is up to date.
> make[3]: Leavin
On Jan 4, 2008 12:58 PM, mabshoff
<[EMAIL PROTECTED]> wrote:
>
>
>
>
> On Jan 4, 9:52 pm, Johannct <[EMAIL PROTECTED]> wrote:
> > fresh rebuild from a vanilla source, LD_LIBRARY_PATH, PYTHONPATH
> > etc... unsetenved, and using make and *not* make -j2 and using
> > SAGE_FORTRAN set to gfortran, I
fresh rebuild from a vanilla source, LD_LIBRARY_PATH, PYTHONPATH
etc... unsetenved, and using make and *not* make -j2 and using
SAGE_FORTRAN set to gfortran, I still stumble :
make[3]: `libcblas.so' is up to date.
make[3]: Leaving directory `/data1/sources/sage-2.9.1.1/spkg/build/
atlas-3.8.p6/AT
I rebuilt in place, and I just realized that I might have issued the
command make -j2 the first time, as I have a dual core machine. So I
am just remaking with this command just to see. If that fails I
will start from a fresh source again.
On Jan 4, 11:18 am, mabshoff <[EMAIL PROTECTED]
On Jan 4, 8:10 pm, Johannct <[EMAIL PROTECTED]> wrote:
> ok, now it fails before numpy seemingly : it did not build all the
> atlas librairies and bail out after complainng that it cannot cp
> them... I relaunched a make, and it seems to build all the libs again,
> which is strange...
> Anyway :
ok, now it fails before numpy seemingly : it did not build all the
atlas librairies and bail out after complainng that it cannot cp
them... I relaunched a make, and it seems to build all the libs again,
which is strange...
Anyway :
cp /data1/sources/sage-2.9.1.1/spkg/build/atlas-3.8.p6/ATLAS-build
On Jan 4, 6:18 pm, Johannct <[EMAIL PROTECTED]> wrote:
Hi Johann,
> hi Josh,
> unsetting the env vars did not change anything seemingly. So I am now
> pointing to gfortran the way you described and I am rebuilding
> everything (id est I just made a make distclean).
Good.
> BTW, I build LPAAC
hi Josh,
unsetting the env vars did not change anything seemingly. So I am now
pointing to gfortran the way you described and I am rebuilding
everything (id est I just made a make distclean).
BTW, I build LPAACK and ATLAS on my own for scipy recently, and it was
absolutely critical to set my dual
We modify numpy so that it is supposed to use sage_fortran, which
wraps either the g95 fortran we include
or a fortran compiler the user specifies. The point of this is to
avoid problems with the user having
multiply incompatible fortran compilers (since there are a bunch)
Unfortunately somethin
hi there,
ok I can't debug the distutils config, it is all arcane for me, but I
noticed that there is a sage-fortran in /data1/sources/sage-2.9.1.1/
local/bin/ , which is just a shell wrapper :
Sage subshell$ more /data1/sources/sage-2.9.1.1/local/bin/sage_fortran
#!/bin/sh
sage_fortran.bin -fPI
well, sorry Michael, it is not in my PATH :) INTEL ships stuff that
get installed in /opt, and I like that as it is not usua;l to have
PATH pointing there, so I make a point not to add it to make sure I
keep using GNU consistently, unless I decide not to do so.
When I have time, I will try to
On Jan 3, 6:43 pm, Johannct <[EMAIL PROTECTED]> wrote:
Hello Johann,
> I think I only installed ifort
In case you have admin rights on the box could you move it out of
$PATH and try again? That seems to be the best lead so far. I hope
Josh has an idea how to fix this if it really turns ou
I think I only installed ifort
On Jan 3, 9:33 am, mabshoff <[EMAIL PROTECTED]
dortmund.de> wrote:
> On Jan 3, 4:33 pm, Johannct <[EMAIL PROTECTED]> wrote:
>
> Hi Johann,
>
> > Hi Michael,
> > I put it afterwards, because of the warning message present in the
> > output. As I said, I did not t
On Jan 3, 4:33 pm, Johannct <[EMAIL PROTECTED]> wrote:
Hi Johann,
> Hi Michael,
> I put it afterwards, because of the warning message present in the
> output. As I said, I did not think there was any relevance, but if on
> top of it it is wrong then the warning should go! For reference I am
>
Hi Michael,
I put it afterwards, because of the warning message present in the
output. As I said, I did not think there was any relevance, but if on
top of it it is wrong then the warning should go! For reference I am
putting the part of the log at the end of this email.
As for sage_fortran.bin,
Hello Johann,
On Jan 3, 9:30 am, Johannct <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] sage-2.9.1.1]$ env
> SSH_AGENT_PID=3331
> HOSTNAME=localhost.localdomain
> SAGE_ATLAS=/usr/local/atlas
This is wrong/unneeded since we now build ATLAS. Did you set this
before or after the build of scipy f
[EMAIL PROTECTED] sage-2.9.1.1]$ env
SSH_AGENT_PID=3331
HOSTNAME=localhost.localdomain
SAGE_ATLAS=/usr/local/atlas
SHELL=/bin/bash
TERM=xterm
DESKTOP_STARTUP_ID=
HISTSIZE=1000
XDG_SESSION_COOKIE=424f99052673e293581389004676f100-1199038684.707549-380548520
PERL5LIB=/usr/lib/perl5/site_perl/5.8.8/i3
It is indeed an FC7 box :
[EMAIL PROTECTED] sage-2.9.1.1]$ uname -a
Linux localhost.localdomain 2.6.23.8-34.fc7 #1 SMP Thu Nov 22 23:05:33
EST 2007 i686 i686 i386 GNU/Linux
On Jan 2, 9:16 pm, Joshua Kantor <[EMAIL PROTECTED]> wrote:
> Hmm. That is very weird that it saw your system as posix and n
On Jan 3, 6:16 am, Joshua Kantor <[EMAIL PROTECTED]> wrote:
> Hmm. That is very weird that it saw your system as posix and not
> linux.
> Out of curiosity what does uname -a output on your system.
>
It looks like a current Fedora Core 7:
UNAME: Linux localhost.localdomain 2.6.23.1-21.fc
Hmm. That is very weird that it saw your system as posix and not
linux.
Out of curiosity what does uname -a output on your system.
On Jan 2, 5:34 pm, Johannct <[EMAIL PROTECTED]> wrote:
> hi,
> I downloaded sage-2-9-1-1 and I am running on the following system :
>UNAME: Linux localhost.lo
33 matches
Mail list logo
