Transitioning from g77 to gfortran

We would like to present the G77 to gfortran transition as a Lenny release goal. The Debian developers responsible for the transition are Riku Voipio < riku.voipio@iki.fi > (fortran application and library packages) and Mathias Klose < doko@debian.org > (toolchain packages). For discussion, please use < debian-toolchain@lists.debian.org > mailing list.

Why

Upstream released the last version of the g77 front end with GCC-3.4. gfortran 4.3 is now considered a viable replacement for g77. However, code must not link at the same time against -lg2c and -lgfortran. To allow partial upgrades we need to rename *all* library packages built with g77 and linked against g2c when they are rebuilt with gfortran.

Once the transition is completed, we are able to remove GCC-3.4 from the distribution (gpc needing an update for GCC-4.1 as well).

How

If your package build-depends on g77, you need to adjust your build-depends from g77 to gfortran. If you build-depend on a library package containing a shared library linked against libg2c, wait until all of these libraries are rebuilt with gfortran. Tighten the build-depends on those lib*-dev packages to the first version built with gfortran.

If your package provides a library that exports fortran functionality, it needs to be renamed. The recommended suffix for the new package name is "gf". If your package is affected by also by the long double transition, you can choose whichever suffix for your library. If you upgrade to a new upstream version of a library with a different soname, just use the new upstream name. It is a good idea to use the debian scheme for the library packages (e.g. libfoo3, libfoo-dev, instead of foo3, foo-dev).

Finally, if you now ship same files in different packages (such as a library in /usr/lib), you need to Conflict and Replace with the old package.

Fixing current packaging mistakes

Some packages did already start using gfortran without renaming the library package or with build-depending on gfortran and a library still built with g77. This needs to be fixed.

Example

For example:

Package: libfoo3
Binary: foo3, foo3-dev, foo3-doc
Build-Depends: debhelper (>= 4), g77, bar3-dev

Package: libfoo3
Binary: libfoo3gf (or libfoo3 if the name is different than the original one), foo3-dev, foo3-doc
Build-Depends: debhelper (>= 5), gfortran, bar3-dev (>= <first version built with gfortran)
...
Package: libfoo3gf
...
Replaces: foo3
Conflicts: foo3

Possible Issues

Some of the command line options supported by g77 have been dropped. You can usually just drop them.

On ia32, you might need to use the -ffloat-store option for gfortran to achieve identical behaviour with floating points. This was at least the case for refblas3. This option will have strong negative impact on performance. On amd64, the SSE registers are used by default in the platform ABI. So REAL and DOUBLE PRECISION variables will be carried in 32-bit and 64-bit registers rather than the x87 unit's 80-bit registers. The possible inconsistent precision/optimization problems worked around by -ffloat-store do not apply, but intermediate computations will not be carried to 80 bits. Some results may be less accurate, but they also should be consistent with other limited platforms (e.g. Power, Sparc).

One other caveat with precisions. g77 follows the f2c convention of returning a single-precision value from a function in a double-precision type (including complex). gfortran (and most other compilers) return a value in the same type. On ia32 and ia64, this isn't an issue; everything is returned in an 80-bit register anyways. But if you encounter strange problems with single-precision real or complex functions causing segfaults, check that the return types actually match. If the caller expects one size and the callee provides another, all sorts of stack fun occur. This occurs most often with C code that expects the Fortran compiler to follow the f2c ABI. gfortran can generate code with the f2c ABI, but then intrinsics will not function properly, so don't do it.

getarg and some other g77 specific functions have been removed from gfortran. See [http://lists.debian.org/debian-toolchain/2007/07/msg00013.html this posting] to workaround this in gfortran. For some packages (like mpich), other distributions may have worked around the issue already, so their fixes can be made use of, like in the case of mpich, for which a GETARG fix from ?SuSe seems to work (see [http://bugs.debian.org/195509 #195509]).

Ask on debian-toolchain list for any other issues.

Status

The current status can be seen [http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=gfortran;users=debian-toolchain@lists.debian.org in the BTS].

The following packages do exist in two versions to allow a smoother migration. you need to rename the build dependencies:

See the source packages blas, lapack and atlas for further renames.

Legend

(./)

Transitioned

<!>

Has issues

{X}

Unfixed / Needs upload

{1}

Ready for binNMU

{2}

Ready for NMU/upload

{o}

Depending packages need to migrate first

{i}

In experimental / NEW

Package

State

Trivial packages

use g77 but do not use or provide fortran libs

cfitsio3

(./)

fftw3

{X} (compiled with gfortran -f2c)

libtool

{X} [http://bugs.debian.org/441751 #441751]

med-fichier

(./)

minpack

(./)

multimix

(./) [http://bugs.debian.org/449458 #449458]

pvm

(./)

saods9

{2} [http://bugs.debian.org/449456 #449456]

zivot

(./)

main knot

status

needs library rename

atlas3

(./)

yes

cernlib

(./)

yes

dsdp

(./)

no

fftw

(./)

no

geant321

(./)

yes

gsl

(./)

no

lam

(./) (Not built on alpha due to a GCC bug which is fixed upstream)

yes

lapack3

(./)

yes

libextutils-f77-perl

{X} doesn't gfortran make this obsolete?

mclibs

(./)

yes

mn-fit

(./)

no

mpich

(./)

yes

netcdf

(./)

no

octave2.1

(./)

no

octave2.9

(./) (dummy package, part of octave3.0 since version 3.0.0-2)

no

octave3.0

(./)

no

paw

(./)

yes

petsc

(./)

no

refblas3

(./)

yes

suitesparse

(./)

yes

Leaf packages

|can be fixed as soon as all their dependencies have been transitioned

abinit

(./)

arpack

<!> Never built on all architectures ([http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467327 467327] - fix is [http://lists.alioth.debian.org/pipermail/pkg-scicomp-devel/2008-March/002258.html pending])

arpack++

{2} (wait for arpack) [http://bugs.debian.org/463931 #463931] (patch submitted to BTS)

blacs-mpi

(./) [http://bugs.debian.org/465366 New]

blacs-pvm

(./)

blitz++

(./)

cvxopt

(./)

illuminator

{X}

ghemical

{2} [http://bugs.debian.org/463948 #463948] (patch in BTS, wait for libghemical)

gretl

(./)

gromacs

{o} fftw3 lam

harminv

{2} [http://bugs.debian.org/463953 #463953] (NMU uploaded to delay 5)

k6fftwgel

{2}

k7fftwgel

{2}

kst

{o} cfitsio3 gsl

libghemical

{2} [http://bugs.debian.org/465716 #465716] (patch in BTS, wait for mopac7)

lush

(./)

meep

{o} harminv mpich

mopac7

{2} [http://bugs.debian.org/465723 #465723] (patch in BTS, uses f2c - is that all right?)

mpb

{2} [http://bugs.debian.org/467351 #467351] (patch submitted to BTS)

mpqc

{2} [http://bugs.debian.org/463968 #463968] (patch submitted to BTS)

octave2.1-forge

(./)

octaviz

(./)

octplot

(./)

openmx

(./)

p4fftwgel

{2}

pdl

{2} [http://bugs.debian.org/468637 #468637] (patch in BTS)

pfstools

{X}

psicode

(./)

pysparse

(./)

python-numarray

(./)

python-numeric

(./)

python-numpy

(./)

python-scipy

(./)

r-base

(./)

r-noncran-lindsey

{2} [http://bugs.debian.org/462233 #462233]

scalapack

{2} [http://bugs.debian.org/465392 #465392]

semidef-oct

(./)

tela

{o} libhdf4 orphaned

wsjt

<!> build-depends on libg2c0-dev *and* gfortran??