CVS build just failed
Hi all, I'm trying to build CVS scipy on a new Fedora Core 2 box, and I'm failing pretty early on. I suspect the problem is with f2py and not scipy itself. Here's the error: ... compiling Fortran sources g77(f77) options: '-Wall -fno-second-underscore -Vaxlib -i_dynamic -O3 -funroll- loops -march=pentium4 -mmmx -msse2 -msse -malign-double -fomit-frame-pointer' ifc(f90) options: '-Vaxlib -i_dynamic -Vaxlib -i_dynamic -O3 -funroll-loops -mar ch=pentium4 -mmmx -msse2 -msse -malign-double -fomit-frame-pointer' ifc(fix) options: '-Vaxlib -i_dynamic -Vaxlib -i_dynamic -O3 -funroll-loops -mar ch=pentium4 -mmmx -msse2 -msse -malign-double -fomit-frame-pointer' compile options: '-c' g77:f77: Lib/fftpack/dfftpack/dcosqb.f g77: `-V' must come at the start of the command line g77: `-V' must come at the start of the command line error: Command "/usr/bin/g77 -Wall -fno-second-underscore -Vaxlib -i_dynamic -O3 -funroll-loops -march=pentium4 -mmmx -msse2 -msse -malign-double -fomit-frame-p ointer -c -c Lib/fftpack/dfftpack/dcosqb.f -o build/temp.linux-i686-2.3/Lib/fftp ack/dfftpack/dcosqb.o" failed with exit status 1 ### I grabbed the latest f2py from the webpage a moment ago (2.43.239_1844) and the scipy is current CVS. Any help would be much appreciated. best, f
On Mon, 11 Oct 2004 Fernando.Perez@colorado.edu wrote:
Hi all,
I'm trying to build CVS scipy on a new Fedora Core 2 box, and I'm failing pretty early on. I suspect the problem is with f2py and not scipy itself. Here's the error:
... compiling Fortran sources g77(f77) options: '-Wall -fno-second-underscore -Vaxlib -i_dynamic -O3 -funroll- loops -march=pentium4 -mmmx -msse2 -msse -malign-double -fomit-frame-pointer' ifc(f90) options: '-Vaxlib -i_dynamic -Vaxlib -i_dynamic -O3 -funroll-loops -mar ch=pentium4 -mmmx -msse2 -msse -malign-double -fomit-frame-pointer' ifc(fix) options: '-Vaxlib -i_dynamic -Vaxlib -i_dynamic -O3 -funroll-loops -mar ch=pentium4 -mmmx -msse2 -msse -malign-double -fomit-frame-pointer' compile options: '-c' g77:f77: Lib/fftpack/dfftpack/dcosqb.f g77: `-V' must come at the start of the command line g77: `-V' must come at the start of the command line error: Command "/usr/bin/g77 -Wall -fno-second-underscore -Vaxlib -i_dynamic -O3 -funroll-loops -march=pentium4 -mmmx -msse2 -msse -malign-double -fomit-frame-p ointer -c -c Lib/fftpack/dfftpack/dcosqb.f -o build/temp.linux-i686-2.3/Lib/fftp ack/dfftpack/dcosqb.o" failed with exit status 1
### I grabbed the latest f2py from the webpage a moment ago (2.43.239_1844) and the scipy is current CVS. Any help would be much appreciated.
f2py has little to do with this failure, it's more scipy_distutils or an end-user issue. For some reason g77 is used for Fortran 77 codes and ifc for Fortran 90 codes, and the compiler flags get mixed up. Such a situation should not happen normally as whenever you specify Fortran compiler to be ifc, it should be used both for Fortran 77 and 90 codes. How did you specified fortran compilers? What command line are you using for building scipy? The correct way to specify ifc is: python setup.py config_fc --fcompiler=intel build Just check, building scipy CVS works ok on a Debian box using the latest f2py and intel fortran compilers 7.1 and 8.0. Although compiling Lib/linalg/iterative/getbreak.f fails with ifc-7.1, probably due to a compiler bug. Pearu
Pearu Peterson wrote:
For some reason g77 is used for Fortran 77 codes and ifc for Fortran 90 codes, and the compiler flags get mixed up. Such a situation should not happen normally as whenever you specify Fortran compiler to be ifc, it should be used both for Fortran 77 and 90 codes. How did you specified fortran compilers? What command line are you using for building scipy? The correct way to specify ifc is:
python setup.py config_fc --fcompiler=intel build
Mmh, weird. This is on a new freshly installed machine, but a friend's. I'm not sure how his environment variables were set up; I simply typed python setup.py build without specifying anything else. Is it normal for scipy_distutils to pick up mixed compilers in this case? I guess I can use the line you suggested and just build everything with g77. Could it be that this user's environment was set up in a way which confused distutils? He's not (yet) a python user, so I don't know how much f2py-specific setup he might have in his home account, but perhaps there was some leftover crud from some old project. Which environment variables should I look for which could cause this? Besides getting it to work (which I can do with your suggestion above), I'd like to make sure that for a fresh new user something like this can't accidentally happen. This is the kind of error which tends to discourage new users, so if a bit of additional instructions can prevent it, we can add that to the info on the website. Many thanks for your help! Best, f
On Mon, 11 Oct 2004, Fernando Perez wrote:
Pearu Peterson wrote:
For some reason g77 is used for Fortran 77 codes and ifc for Fortran 90 codes, and the compiler flags get mixed up. Such a situation should not happen normally as whenever you specify Fortran compiler to be ifc, it should be used both for Fortran 77 and 90 codes. How did you specified fortran compilers? What command line are you using for building scipy? The correct way to specify ifc is:
python setup.py config_fc --fcompiler=intel build
Mmh, weird. This is on a new freshly installed machine, but a friend's. I'm not sure how his environment variables were set up; I simply typed
python setup.py build
without specifying anything else. Is it normal for scipy_distutils to pick up mixed compilers in this case?
No. In fact, since scipy does not have any Fortran 90 sources, you shouldn't see the configuration info for fix and f90 compilers at all. And that's most strange behaviour in this case, see fcompiler._compile method for details.
I guess I can use the line you suggested and just build everything with g77. Could it be that this user's environment was set up in a way which confused distutils? He's not (yet) a python user, so I don't know how much f2py-specific setup he might have in his home account, but perhaps there was some leftover crud from some old project.
Which environment variables should I look for which could cause this? Besides getting it to work (which I can do with your suggestion above), I'd like to make sure that for a fresh new user something like this can't accidentally happen. This is the kind of error which tends to discourage new users, so if a bit of additional instructions can prevent it, we can add that to the info on the website.
scipy_distutils/fcompiler.py looks for the following environment variables ( see customize method): F77, F90, F77FLAGS, F90FLAGS, FREEFLAGS, FOPT, FARCH, FDEBUG, FFLAGS, LDSHARED, LDFLAGS, RANLIB, ARFLAGS Check also the output of python gnufcompiler.py --verbose python intelfcompiler.py --verbose python fcompiler.py --verbose Pearu
Pearu Peterson wrote:
without specifying anything else. Is it normal for scipy_distutils to pick up mixed compilers in this case?
No. In fact, since scipy does not have any Fortran 90 sources, you shouldn't see the configuration info for fix and f90 compilers at all. And that's most strange behaviour in this case, see fcompiler._compile method for details.
[...] Thanks, Pearu. I don't have access to this box right now, I'll try to get there tomorrow and report on the tests you suggested. Cheers, f
Pearu Peterson schrieb:
scipy_distutils/fcompiler.py looks for the following environment variables ( see customize method): F77, F90, F77FLAGS, F90FLAGS, FREEFLAGS, FOPT, FARCH, FDEBUG, FFLAGS, LDSHARED, LDFLAGS, RANLIB, ARFLAGS
FFLAGS was the culprit! As I said, this was on a friend's machine using his user account for the build, and he had some explicit FFLAGS set to -Vaxlib... for jobs with the intel compiler. This threw scipy_distutils for a loop, I guess. Many thanks for your help. I don't really know if there is a sensible way to anticipate this for newbies like myself who are so prone to making plain dumb mistakes... Anyway, it's solved, and all tests pass happily with current CVS, Numeric 23.5 and ATLAS for Hyperthreaded P4 from scipy's ATLAS binaries page. Best regards, and sorry for bothering with such a stupid error on my part. Fernando.
participants (3)
-
Fernando Perez -
Fernando.Perez＠colorado.edu
-
Pearu Peterson