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 core to "performance" level for both CPUs. This allows ATLAS to correctly time its performance tests and decode how to build the code. I noticed that SAGE is also performing timing tests, so I went ahead and forced to "performance" my 2 CPUs. But I wonder whether it is necessary, as the SAGE build page does not mention anything about that.... I will let you know how it goes. Johann On Jan 4, 2:01 am, Joshua Kantor <[EMAIL PROTECTED]> wrote: > 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 something is causing this to go awry for you, its > probably an environment variable. > Numpy looks at lots of environment variables and something must be set > on your system that we aren't used to having set. This is causing > numpy to try to use your gfortran. > > based on your env > > The only thing I see that is suspicious is your LD_LIBRARY_PATH > > 1. Please try > > unset F77 > unset SAGE_FORTRAN > unset ATLAS > unset SAGE_ATLAS > unset LAPACK > unset BLAS > unset LD_LIBRARY_PATH > > maybe also > > unset PYTHONPATH > > before building, does this do anything > > 2. An alternative option is to try to use your system gfortran > explicilty. This shouldn't be necessary > but if you want to try it you need to do > > export SAGE_FORTRAN=`which gfortran` > > before building. > > NOTE: > > This will essentially require starting the build over from the start > since anything that used fortran needs to be rebuilt. (or you need to > force the fortran, lapack, blas, and atlas spkgs to rebuild before > continuing with numpy) > > 3. While we are troubleshooting your build problem there are linux > binaries so you can at least > use sage :) > > Josh > > On Jan 3, 9:48 pm, Johannct <[EMAIL PROTECTED]> wrote: > > > 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 -fPIC $@ > > > So I poked this sage_fortran.bin : > > > Sage subshell$ ls -l /data1/sources/sage-2.9.1.1/local/bin/ > > sage_fortran.bin > > -rwxr-xr-x 1 cohen cohen 251656 2008-01-02 16:18 /data1/sources/ > > sage-2.9.1.1/local/bin/sage_fortran.bin > > Sage subshell$ /data1/sources/sage-2.9.1.1/local/bin/sage_fortran.bin > > --version > > G95 (GCC 4.0.3 (g95 0.91!) Jul 17 2007) > > Copyright (C) 2002-2005 Free Software Foundation, Inc. > > > G95 comes with NO WARRANTY, to the extent permitted by law. > > You may redistribute copies of G95 > > under the terms of the GNU General Public License. > > For more information about these matters, see the file named COPYING > > > So this seems to be g95 and not gfortran.... > > Sage subshell$ which g95 > > /data1/sources/sage-2.9.1.1/local/bin/g95 > > Sage subshell$ ls -l /data1/sources/sage-2.9.1.1/local/bin/g95 > > lrwxrwxrwx 1 cohen cohen 12 2008-01-02 16:18 /data1/sources/ > > sage-2.9.1.1/local/bin/g95 -> sage_fortran > > > and my gfortran executable does not seem to be the same : > > > Sage subshell$ which gfortran > > /usr/bin/gfortran > > Sage subshell$ ls -l /usr/bin/gfortran > > -rwxr-xr-x 1 root root 208060 2007-09-25 17:50 /usr/bin/gfortran > > Sage subshell$ /usr/bin/gfortran --version > > GNU Fortran (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27) > > Copyright (C) 2007 Free Software Foundation, Inc. > > > GNU Fortran comes with NO WARRANTY, to the extent permitted by law. > > You may redistribute copies of GNU Fortran > > under the terms of the GNU General Public License. > > For more information about these matters, see the file named COPYING > > > when I try to python setup.py config, the error message is : > > customize Sage_FCompiler > > Couldn't match compiler version for 'GNU Fortran (GCC) 4.1.2 20070925 > > (Red Hat 4.1.2-27)\nCopyright (C) 2007 Free Software Foundation, Inc.\n > > \nGNU Fortran comes with NO WARRA > > NTY, to the extent permitted by law.\nYou may redistribute copies of > > GNU Fortran\nunder the terms of the GNU General Public License.\nFor > > more information about these matters > > , see the file named COPYING\n' > > > So it is not happy with my gfortran, and I am wondering whether it is > > because it compares it to this loca g95 ??? Could that be te problem? > > Note that when I exit from the sage sh, g95 is not in my path anymore, > > so it is really local to the sage build... > > I tried to redirect the g95 soft link to gfortran but it does not > > change anything.... > > > well, hth, > > Johann --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
