For the attached simple project, I get the following error:
bash.exe-3.1$ gfortran -o test.obj -c sfstubsf95.f90
Fatal Error: Reading module plplotp at line 491 column 35: Expected left parenthesis
gfortran.exe: Internal error: Aborted (program f951)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
Note the platform I am using is MinGW/MSYS/Wine. This is not cross-compiled. Instead, I am using the downloaded Windows versions of MinGW (gcc-4.5.0_20100311-2) and MSYS for version 1.1.41 of Wine running on Debian Lenny, I get into the MSYS bash environment with, e.g.,
wineconsole /home/wine/mingw/MSYS/bin/bash.exe
It is possible this is a Wine platform issue but I believe this is unlikely sice I have had success building a complicated C project with the same version of MinGW/MSYS using this Wine platform. Anyhow, a quick experiment with the attached fortran source for this version of MinGW/gfortran on the
Windows platform should clear up that issue.
Requested DETAILS:
bash.exe-3.1$ gfortran -v
Using built-in specs.
COLLECT_GCC=z:\home\wine\mingw\MinGW\bin\gfortran.exe
COLLECT_LTO_WRAPPER=z:/home/wine/mingw/mingw/bin/../libexec/gcc/mingw32/4.5.0/lt
o-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.0_20100311/configure --enable-languages=c,c++,ada,fo
rtran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --ena
ble-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-s
pecific-runtime-libs --disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.0 20100311 (experimental) (GCC)
bash.exe-3.1$ ld -v
GNU ld (GNU Binutils) 2.20
bash.exe-3.1$ uname -a
MINGW32_NT-5.1 raven 1.0.14(0.47/3/2) 2010-03-17 23:02 i686 Msys
I also confirm the issue for the 4.4 version of MinGW (gcc-full-4.4.0-mingw32-bin-2.tar.lzma) . Everything else (MSYS and Wine) was the same.
bash.exe-3.1$ gfortran -o test.obj -c sfstubsf95.f90
Fatal Error: Reading module plplotp at line 121 column 50: Expected left parenth
esis
gfortran.exe: Internal error: Aborted (program f951)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
Requested Details
bash.exe-3.1$ gfortran -v
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.4.0/configure --enable-languages=c,ada,c++,fortran,jav
a,objc,obj-c++ --disable-sjlj-exceptions --enable-shared --enable-libgcj --enabl
e-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enab
le-version-specific-runtime-libs --prefix=/mingw --with-gmp=/mingw/src/gmp/root
--with-mpfr=/mingw/src/mpfr/root --build=mingw32
Thread model: win32
gcc version 4.4.0 (GCC)
bash.exe-3.1$
bash.exe-3.1$ ld -v
bash.exe: ld: command not found
(I double-checked and ld.exe is missing from the "full" 4.4 version of MinGW).
bash.exe-3.1$ uname -a
MINGW32_NT-5.1 raven 1.0.14(0.47/3/2) 2010-03-17 23:02 i686 Msys
Much simpler Fortran source code that demonstrates the issue
I have now investigated the issue a lot further using MinGW 4.5.0 final. All other conditions of the test are the same as stated for the original bug report. Here is how the issue can be confirmed using the recently attached simple.f90 source code:
wine@raven> wine gfortran -o test.obj -c simple.f90
Fatal Error: Reading module plplotp at line 28 column 41: Expected left parenthesis
gfortran.exe: Internal error: Aborted (program f951)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
simple.f90 contains only two subroutines named plvectors_0 and plvectors_1. If I remove or rename either of them the problem disappears. Furthermore, I have done a lot of experiments with the original tarball attachment and found several other pairs of routines whose names seemed to collide with each other as well. Therefore, I suspect I have found a hash collision issue for the subroutine names.
I assume this issue does not occur on the Microsoft Windows platform because otherwise gfortran would never have worked there except for really simple projects that happen not to have colliding subroutine names. However, I am aware of one other Wine issue (http://bugs.winehq.org/show_bug.cgi?id=22286) where they had a poorly implemented version of one of the deprecated Windows hash functions, and I wonder if gfortran is up against a similar hash collision issue for the Wine platform? I don't have the developer expertise to take this speculation any further myself, but it appears to me it would be worthwhile for the MinGW developers to review the hashing code used for subroutine names when reading module files, and I would certainly be happy to test any improvements they want to try for that code.
Since this is a Wine project issue I'm closing as invalid.
On 2013-02-07 20:36-0000 Earnie Boyd wrote:
Hi Earnie:
I am still not entirely sure this was a Wine project issue. However, a
recent upgrade to MinGW-4.7.0 and wine-1.5.19 finally got rid of the
issue for me so closing the bug is appropriate regardless of
the source of the issue.
Alan
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
Linux-powered Science