Severe issue with gfortran (from gcc) with binary builds

Thomas Robitaille thomas.robitaille at gmail.com
Thu May 17 01:57:41 PDT 2012


Hi all,

I've identified a major issue which occurs with gfortran in MacPorts,
but since I can't identify which dependency is responsible (all I know
is that it's due to the binary builds), I thought I'd post here to ask
for help.

To give some background, Fortran has the option to declare floats
using real(kind) where kind is a number related to the default
precision, and typically (although not in the fortran standard) this
corresponds to the number of bytes used to store values. So real(4) is
a 32-bit float, real(8) is a 64-bit float, etc. All major fortran
compilers stick to this convention for reasons of backward
compatibility. However, the standard now recommends (looking to the
future) that rather than use e.g. 4 or 8, one uses helper functions to
determine the correct kind for a desired precision. So with all major
compilers (including gfortran), the following code:

program test

implicit none

print *, selected_int_kind(13)
print *, selected_real_kind(p=6,r=37)
print *, selected_real_kind(p=15,r=307)

end program test

returns

8
4
8

However, after upgrading outdated ports recently, the macports
gfortran suddenly returned

16
8
10

which is making it impossible to compile a lot of legacy code (and
causes values to take up twice as much RAM). What happened was that
one of the dependencies for gcc got upgraded to the binary build, and
this causes all the different versions of gfortran (from gcc43 to
gcc47) to change their output (without being upgraded themselves,
which tells me that it is an issue with a dependency, not gcc itself).

If I install MacPorts (on 10.7) then gcc45 from scratch with binary
packages, the issue is there. If I install all packages from scratch
with the -s flag, the issue disappears. This suggests to me that there
is an issue with one of the binary builds.

Of course, the temporary solution for me is simply to force the -s
flag to always be used, but I think this issue should be fixed, as it
makes the gfortran compilers in MacPorts unusable otherwise.

Any ideas?

Thanks,
Tom


More information about the macports-dev mailing list