Bug 173258
| Summary: | Failed to compile SciPy (gfortran) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | icy-flame <icy_flame_hm> |
| Component: | gcc4 | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-11-21 09:18:29 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
just realise the beginning of the comment is missing, here it is: I was able to compile SciPy (www.scipy.org) on FC2 and FC3, but failed on the FC4. If you want to link code compiled by g77, link it either with g77 instead of gcc, or link using gcc32. Now, regarding gfortran and SciPy, please try either rawhide gfortran (or better yet GCC SVN trunk) first. Many bugs have been fixed and many features added recently. If you can still reproduce some problem, please create a small self-contained testcase from it and submit that here or to http://gcc.gnu.org/bugzilla/. |
Description of problem: rg) on FC2 and FC3, but failed on the FC4. Brief google checking seems to suggest this is a generic problem for FC4. The following is a fairely good desription of the problem I found on news group. On Wed, 2005-10-19 at 10:35 +0100, Morgan Hough wrote: > I have checked the archives as best I can and I don't see any mention > of this so here goes. SciPy is a great python numerical package which > is also a dependency for many specialized scientific packages. > Apparently there is a problem with gcc-4.0.1's fortran support and > SciPy can't be built on an fc4 system (without third party commercial > software). Here's a more complete description of the problem from the > SciPy-users list: > > <quote> > In an all-default configuration, it is not presently possible to build a > working scipy on Fedora Core 4, either old or new. There is a bug in > gfortran which causes it to mis-compile the i1mach, r1mach, and d1mach > functions which are at the bottom of much of the Fortran code in scipy. > If you use g77 instead by using the appropriate compatibility RPMs > (compat-gcc-32-g77 and compat-libf2c-32), you'll find that gcc4 cannot > link to libg2c because it isn't in a directory which gcc4 searches. I > haven't found a way of forcing a scipy build to use gcc 3.2.3 (the > compatibility version which is part of FC4). > > The only feasible workaround I've found is to use g77 on FC4 to build > scipy (and Numeric and numarray), and create symbolic links to libg2c.a > and libg2c.so so that gcc4 can find them. That is, do the following: > > ln -s /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/libg2c.so > /usr/lib/gcc/i386-redhat-linux/4.0.1 > ln -s /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/libg2c.a > /usr/lib/gcc/i386-redhat-linux/4.0.1 > > This is not supported, use at your own risk, your mileage may vary, > results are not guaranteed, pressure RedHat to release a gcc 4.0.2 > update for FC4 in which the gfortran bug is fixed. Personally, I'm > using Absoft Fortran on gcc4; if you're an educational institution, > Intel will let you download and use their Fortran compiler for free. > Both seem to work fine with newscipy and FC4. > </quote> Version-Release number of selected component (if applicable): How reproducible: everytime, every system Steps to Reproduce: 1. Redownload the source code 2. Compile at different location as root Actual results: Exit on error half way Expected results: Be compile Additional info: