Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 236444

Summary: numpy bug exposed via scipy build process?
Product: [Fedora] Fedora Reporter: Jef Spaleta <jspaleta>
Component: numpyAssignee: Jarod Wilson <jarod>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: jspaleta
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-04-17 15:49:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 236670    

Description Jef Spaleta 2007-04-14 05:01:00 UTC
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'

Comment 1 Jarod Wilson 2007-04-16 21:50:17 UTC
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...

Comment 2 Jef Spaleta 2007-04-16 23:49:40 UTC
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  



Comment 3 Jarod Wilson 2007-04-17 01:51:45 UTC
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?

Comment 4 Jef Spaleta 2007-04-17 02:05:50 UTC
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? 

-jef

Comment 5 Jarod Wilson 2007-04-17 03:26:41 UTC
Ticket filed upstream:

http://projects.scipy.org/scipy/numpy/ticket/500

Comment 6 Jarod Wilson 2007-04-17 15:49:42 UTC
Okay, an updated numpy build just finished, I've been able to successfully build
and f95 scipy w/it.

http://buildsys.fedoraproject.org/logs/fedora-development-extras/31674-numpy-1.0.1-4.fc7/