Seems the output of gfortran --version recently changed, dropping the '95' bit. This breaks the build of scipy. Was there a particularly good reason for that to be dropped? Can we get that back in there, or should we get numpy/scipy patched up to account for this change? +++ This bug was initially created as a clone of Bug #236444 +++ Here's the deal. I'm trying to track down a problem in scipy and I'm now running into problems building scipy in the development tree. It looks to me like setup.py process is failing to recognize that gfortran is available on the system becuase the gfortran --version string is an unexpected value. All of the fcompiler detection used by setup.py is actually a part of the numpy package. And from the traceback below it certaintly looks like the problem lies in numpy. Could find the cycles and try to help me figure out if there really is a problem in numpy? Or failing that a way to work around the problem so I can get scipy to build again? From the numpy changelog it looks like you applied a patch to numpy just a couple of days after i built scipy in develop. Here's the warning and traceback that I get when trying to compile the srpm against the current devel tree. Something has definitely changed with regard to numpy since the last time scipy was built. If I punt and build against f77 from compat-gcc-34-g77-3.4.6-7, things appear to work.. something is definitely broken with the gfortran compiler detection. I can confirm that /usr/bin/gfortran is on the system, and the same problem happens under mock as well as under a local environment. warning: build_ext: fcompiler=gnu95 is not available. Traceback (most recent call last): File "setup.py", line 55, in <module> setup_package() File "setup.py", line 47, in setup_package configuration=configuration ) File "/usr/lib/python2.5/site-packages/numpy/distutils/core.py", line 174, in setup return old_setup(**new_attr) File "/usr/lib/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/usr/lib/python2.5/distutils/dist.py", line 974, in run_commands self.run_command(cmd) File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/lib/python2.5/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/usr/lib/python2.5/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/lib/python2.5/distutils/dist.py", line 994, in run_command cmd_obj.run() File "/usr/lib/python2.5/site-packages/numpy/distutils/command/build_ext.py", line 121, in run self.build_extensions() File "/usr/lib/python2.5/distutils/command/build_ext.py", line 407, in build_extensions self.build_extension(ext) File "/usr/lib/python2.5/site-packages/numpy/distutils/command/build_ext.py", line 312, in build_extension link = self.fcompiler.link_shared_object AttributeError: 'NoneType' object has no attribute 'link_shared_object' -- Additional comment from jwilson on 2007-04-16 17:50 EST -- Hrm. Best as I can tell, numpy 1.0.1-3 shouldn't be behaving any differently here than numpy 1.0.1-1 from back in december. The -2 bump only altered obsoletes/provides, the -3 bump only included a patch to fix up cpu type detection (and the files that patch touched aren't showing up in the spew there). Odd. Test rebuild of numpy itself is fine, I'll keep poking later this evening... -- Additional comment from jspaleta on 2007-04-16 19:49 EST -- yeah its a little weird... i didnt do anything to the scipy codebase either. I just attempted a rebuild to trackdown something else and blamo. Has gfortran been updated since numpy? It looks like it has. Perhaps gfortran is throwing a new version string which numpy doesn't recognize? I think numpy tries to detect compiler version by running gfortran --version This works just fine on current fc6, and was working fine just after the last numpy patch and rebuild. ti's a mystery. -jef -- Additional comment from jwilson on 2007-04-16 21:51 EST -- Yep, looks like its gfortran throwing a wrench in the works. On devel: $ f95 --version GNU Fortran (GCC) 4.1.2 20070403 (Red Hat 4.1.2-8) [...] On FC6: $ f95 --version GNU Fortran 95 (GCC) 4.1.1 20070105 (Red Hat 4.1.1-51) [...] And numpy/distutils/fcompiler/gnu.py looks for a version string starting with "GNU Fortran 95". Now... The best way around this?... File bug against gfortran or patch numpy somehow? -- Additional comment from jspaleta on 2007-04-16 22:05 EST -- I think we need to approach the gcc-gfortran maintainer about a patch, since that is where the underlying changed happened. If that can't be patched then numpy will need the patch. Is upstream numpy aware of this issue already?
See http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00320.html and http://gcc.gnu.org/PR31050 The change was intentional, GNU Fortran doesn't support just Fortran95, but also Fortran77, partly Fortran2003, ...
Okay upstream numpy definitely has to be made aware of this intentional change. The version scraping numpy does is going to fail moving forward. -jef
Okay, ticket filed with the numpy folks: http://projects.scipy.org/scipy/numpy/ticket/500