[lsb-discuss] LSB and Fortran
Robert.Schweikert at abaqus.com
Wed Aug 2 09:55:59 PDT 2006
On Wed, 2006-08-02 at 17:16 +0200, Tobias Burnus wrote:
> Robert Schweikert wrote:
> > We need Fortran in the LSB and here is how I think this should work:
> > - specify a Fortran RTE library (libfort.so or whatever gFortran is
> > doing) this library contains the intrinsics from the F95 standard and
> > nothing else.
> GCC 4.2.x will have libgfortran.so.2, GCC 4.1.x has libgfortran.so.1.
> (And one should not talk about gfortran of GCC prior 4.1.x.)
I expect that for LSB 4.0 gcc 4.x will be the compiler of choice, thus I
am hoping that this will not be an issue.
> > - specify a calling convention between C and FTN (for example the
> > length of a string is a hidden argument at the end of the argument
> > list)
> Is this not part of Fortran 2003 ("bind(C)")? Note, however, that most
> Fortran compilers do not yet support this part of Fortran 2003
> (especially gfortran does not).
> For C bindings in Fortran, see ISO Fortran 2003 standard or the latest
> draft available at
> It is covered in "Section 15: Interoperability with C".
As you said, 2003 coverage in Fortran compilers is small, secondly there
is a convention being followed already by all UNIX compiler, thus
incorporating this convention into the LSB without waiting for 2003
support in compilers should be an achievable goal. In addition different
vendors will implement 2003 support at different rates, thus vendors
supporting multiple platforms cannot switch to using 2003 features until
the last platform vendor has 2003 support in their compiler. My
prediction here is 2010.
> > Why is Fortran needed?
> > As an example for the problem created by not having Fortran I would like
> > to use the MKL (Math Kernel Library; BLAS implementation) from AMD and
> > Intel for x86-64 (Opteron and EM64T) as an example. AMD claims that
> > their implementation of the MKL is much faster on the Opteron chip than
> > Intel's. This difference can be observed in benchmarks, thus it would be
> > nice if applications such as ours could switch between the Intel MKL and
> > the AMD mkl at runtime.
> This will be difficult as one library is called libamcl.so and the other
> libmkl.so, both require (depending on the program) a couple of other
There are ways around the name problem and the dependent library
> If you talk about ms optimazation, what speaks against compiling once
> for Intel's MKL and once for AMD Core Math Library?
One would have to use two different compilers which means double the QA
effort, who knows how many bugs etc. Not an option for a large
> If one links
> "-lgfortran" one can use the gfortran compiled AMCL version also with
> the intel compiler.
Yes, that's the idea. A Fortran library with a defined set of
interfaces, then it doesn't matter who produces this library. AMD can
link against libgfortran and I can sneek in libMyFortran at runtime. But
because the interfaces in both libraries are the same the AMD mkl will
never know it is not actually using libgfortran.
> > However, since AMD's MKL is compiled with
> > Fortran and they refuse to use the Intel Fortran compiler
> "compiled with Fortran" is misleading. It is compiled with (several
> different) Fortran compilers, which however misses the Intel Fortran
> compiler (for Linux, for Windows it exists).
> > In addition Novell/SUSE doesn't even provide any
> > Fortran rpm with their distribution.
> This is definitly wrong. Look for the package gcc-fortran, which
> contains gfortran.
> A recent snapshot of gfortran 4.1.x you can find in the Factory tree.
> See also http://gcc.gnu.org/wiki/GFortranDistros (and
Oh yes, "Starting from SUSE Linux 10.0,...", I should have qualified
this. Unfortunately we don't get to support only the latest and
> > An LSB Fortran run time environment specification would force
> > distributions to provide a generic RTE for Fortran and based on this we
> > could probably convince Intel to provide an RTE with all the expect
> > interfaces as well. The end effect is that the AMD MKL could run against
> > the Intel RTE.
> Note first that the gfortran development is still a bit in a flux.
> gfortran 4.0 was barely useable, 4.1.0 was kind of ok and only now
> (4.1.x, x > 0 and 4.2) it became really useful. It still misses the
> allocation enhancements of TR15581.
I do realize this, but the LSB 4.0 is probably 2 years away and by that
time gfortran should be in much better shape. The idea here is to get
this on the radar now and hopefully by the time LSB 4.0 comes around
there will be a workable solution.
> The other problem with defining libgfortran.so is that many compilers
> put a lot of work in their fortran library (mathmul, write, etc.). The
> differences in this library is one of the reason for the speed
> difference between compilers.
> I think it could make sense to define libgfortran so that one can ship
> programs and libraries without the need to include libgfortran.* in the
> package, but I don't see that it will achieve what you want.
Robert Schweikert MAY THE SOURCE BE WITH YOU
(Robert.Schweikert at abaqus.com) LINUX
Phone : 401-276-7190
FAX : 401-276-4408
More information about the lsb-discuss