This is the mail archive of the
mailing list for the GNU Fortran project.
Re: changing build dependencies in a distribution from g77 to gfortran
- From: Janne Blomqvist <Janne dot Blomqvist at tkk dot fi>
- To: Matthias Klose <doko at ubuntu dot com>
- Cc: fortran at gcc dot gnu dot org, Henrik Nilsen Omma <henrik at ubuntu dot com>, Camm Maguire <camm at enhanced dot com>, "Kevin B. McCarty" <kmccarty at Princeton dot EDU>
- Date: Fri, 26 Jan 2007 19:07:09 +0200
- Subject: Re: changing build dependencies in a distribution from g77 to gfortran
- References: <45B9DF30.email@example.com>
Matthias Klose wrote:
Some months ago, the GCC/gfortran developers asked distributors to still
ship g77 in their next release of a distribution. Looking forward at
the Debian etch release on the horizon and at upcoming Ubuntu releases,
I had a first look at making g77 the secondary choice as a f77 compiler,
or removing it from the release altogether and using gfortran as the
preferred f77 compiler.
IMHO as of gcc 4.2, or perhaps even 4.1, gfortran is stable enough to be
generally usable as the system Fortran compiler. Of course, if you want
100% bug-for-bug compatibility with g77, then g77 is your only option.
I tried to build numpy using gfortran on i486, starting with the build
dependencies (which are for debian/ubuntu refblas3, lapack3, atlas3).
- the refblas3 package builds, but some complex number tests fail.
Whether this is a bug in gfortran, (mis)use of aggressive optimization
(e.g. -ffast-math), a bug in the test harness or whatever is hard to say
without more information.
Questions that did come up on this check:
- If you want to use the gfortran driver as a g77 replacement, it should
understand all of g77's command line options, or maybe a gfortran
wrapper should be used.
Yes, as Steve Kargl said, gfortran will almost certainly never support
all the compiler options g77 supports. It's a different compiler.
- Are test failures for code that works well when compiled with g77
be seen as regressions in gfortran's f77 mode?
To be pedantic, gfortran doesn't have a "f77 mode". Anyways, inability
to produce a correctly working binary from standard-conforming F77 would
be a bug. gfortran also supports a number of extensions, while not the
same set of extensions as g77 there is still a lot of overlap. But there
might be a number of explanations for the test failures that don't prove
to be bugs.
- Is code, which is party built with g77 and partly built with gfortran,
supposed to work? This situation comes up when starting to build
some packages with gfortran, while others are still built with g77.
This is a real concern for distributions like debian supporting
partial upgrades of packages.
This is going to be a problem. But as debian has made a number of
successful ABI transitions (at least two for C++, and the libc5->glibc
one?), I'm sure you can figure it out.
The basic problem is that by default g77 uses the f2c ABI, thus
inheriting some weirdness, while gfortran uses basically the same as
C99. See the -f2c option in the manpage and
Of course, you can choose to always use -f2c with gfortran, but then
you'll be incompatible with everyone else. As well as possibly take a
small performance hit, issues with excess precision etc.
In addition to ABI issues, there might also be problems e.g. with
library code doing I/O, if the library depends on main() initializing it
before handing over to the user code (at least gfortran does this, don't
know about g77).
Personally I believe the best solution is not to mix gfortran and g77.
Although I have broken this rule myself by using e.g. the ubuntu
packages for atlas, lapack and netcdf together with gfortran and if one
is really careful it might work (mostly).
And just to make your life even more miserable, there will be ABI
breakage in libgfortran in the not too far future. IIRC 4.2 bumped the
so version from 4.1, and it will probably happen again for 4.3.
Hopefully we'll get symbol versioning for 4.3 and thus get some
semblance of ABI stability, courtesy of yours truly, but the patch has
stalled due to some minor problems and I'm quite busy with Real Life(TM)
at the moment so I haven't had time to look into it. :(
- Does the long double change (64->128) on alpha, powerpc, sparc, s390
has consequences for gfortran and on C/C++ libraries interfacing
with g77/gfortran code?
Gfortran pretty much follows the C ABI. I don't know about g77, except
for the f2c weirdness I'd guess it also follows C.
I'm aware that the fortran ML may not be the ideal forum to discuss
this; maybe we can move these conversations to distribution specific
lists after some time.
Well distributions are big "customers" as you put gfortran into the
hands of many users, so I think it's nice that you take an interest in
Another thing you might want to consider is that now that you're
providing a Fortran 95 compiler, presumably other developers will want
to add F95 libraries that provide module files (say, the F90 interface
to netcdf, lapack95 etc.). Coming up with a policy for these .mod files
(where should they go?) might be easier now than a few years later when
you have a few dozen libraries doing it their own way. IIRC the default
is to put them into the normal include directories, but since they are
somewhat system(?) and compiler version dependent you might want to put
them somewhere else. Or then not, it's up to you of course.