changing build dependencies in a distribution from g77 to gfortran

[Matthias Klose <doko at ubuntu dot com>]

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.

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.
  Compiler options used in the build are not recognized by gfortran.

- the lapack3 package (3.0.something) builds.

- numpy can be convinced to build.

- didn't try to build atlas3 yet.

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.

- Are test failures for code that works well when compiled with g77
  be seen as regressions in gfortran's f77 mode?

- 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.

- 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?

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.

  Matthias