Am Tue, 14 Jul 2009 14:15:53 -0600
schrieb Ed Hartnett <ed@xxxxxxxxxxxxxxxx>:
> In practice it means you must build netCDF for every fortran compiler
> you want to use on the machine.
Yeah... I am realizing that there seems to be no library ABI for a compiled
language besides that (not perfect, but mostly working) practice with C libs.
> Including netCDF in your distribution is probably a bad idea. You
> don't want to take this on, believe me.
Well, I wouldn't like this one, too. I already feel relieved not distributing
libtool's libltdl withing mpg123 sources anymore (where the practice of
including a copy has been encouraged), as already that caused too much trouble.
I wont't argue on that one;-)
> The mess with the fortran libraries is even worse than you imagine.
> The F90 library is based on the F77 library, which is really a C
> library pretending to be Fortran 77 for your compiler, and which then
> calls the "real" netCDF C library.
That is what I understood so far (external function definitions in the include,
corresponding symbols in the NetCDF C lib).
But, quoting Magnus:
> this doesn't help you since it also applies to the f77 lib. Here it
> is a name mangling issue since different compilers expect different numbers
> of under scores appended to procedure names. you cannot win this one...
Does the NetCDF F77 lib "emulation" also suffer from compatibility problems
between compilers?
I would suspect that not, but perhaps by incident only for a particular set of
compilers?
> This was all necessary because there was (until F2003) no standard
> C/Fortran interoperability.
Splendit. So, _no_ common way of getting outside code in use for your project
besides copying the source code, in a world that does not have a comfortable
supply of (fully) Fortran 2003-compliant compilers.
At least that is what Fortran users experience, because most of them (erm,
scientists) do not care about differing compiler versions and just see that
things break if they use external libs and something in the toolchain changes.
That explains a lot, like the very popular practice of downloading pieces of
code from netlib instead of installing a LAPACK lib. There's outdated versions
of various codes all around.
Fear of external dependencies.
But then, another reason may be to keep the own code as predictable as
possible, not changing numerical algorithms (and bugs in them;-) by moving to a
different machine; an issue that I do not see with NetCDF.
> The conversion of the current system to one based on Fortran 2003 will
> clear away much of the confusion, but will not eliminate the
> requirement for the netCDF fortran compiler to match the fortran
> compiler for your particular application.
Hm, I am already a very "progressive" Fortran user by starting with Fortran 90
and parts of the Fortran 95 extensions (though, I had to learn that forall
loops are a bad idea, generally). And even there I learned to stay clear of not
thought-out stuff like subroutines as dummy arguments. Suggesting to folks that
one should use Fortran 2003 seriously would get me suspicious looks and the
occasional laugh, half stuck in the throat.
But I feel a frustrated slipping through... so, eh... I better stop.
Still, I fail to see a reason for the Fortran 2003 standard not specifying
Fortran/Fortran interoperability. Strange world.
But thanks for your care to discuss this. Also to the other people who gave
suggestions on how to manage things. And yes, of course you can do shell logic
to handle different setups; indeed I do that for choosing the compilers already.
The issue is to get the clear structure of lib/compiler/.. somehwere. Though, I
rather would not like to put binary, architecture dependent files into a
include/ sub-directory (like /usr/include/netcdf.mod), more like
/opt/sun_studio12/include/netcdf.h, /opt/sun_studio12/lib/libnetcdf.a ... the
.mod file also being somewhere under libm lib/f90 or whatnot.
Alrighty then,
Thomas.
--
Dipl. Phys. Thomas Orgis
Atmospheric Modelling
Alfred-Wegener-Institute for Polar and Marine Research
