Am Tue, 14 Jul 2009 15:51:54 +0100
schrieb Magnus Hagdorn <Magnus.Hagdorn@xxxxxxxx>:
> On Tue, 2009-07-14 at 16:38 +0200, Thomas Orgis wrote:
> > Java got a defined binary format, but somehow it did not encounter
> > to C++ and Fortran 90 designers to care about interoperability of
> > code.
> >
>
> F90 source code is portable (as long as it is standard conforming and
> you have a decent compiler...)
I meant binary code, of course. And yes, it's painting over the cracks in the
wall for C, too, when it comes to funny stuff like differing stack alignment
between compilers. I had that with the libmpg123 C library that includes SSE
assembly code (which could be generated by an optimizing compiler), needing
certain alignment for data. A different compiler using the library can have a
different stack alignment and thusly trigger crashes quickly. But the binary
format as such is compatible between compilers (since usually there are not so
many sensible possibilities to hand over function arguments, or there is a
clear convention).
These nasty effects of differing alignment and clash with the frenzy of ad-hoc
mutations of the x86 architecture could also be blamed on the philosophy of x86
at all...
And: Current GCC has a safeguard against this breakage, so the only thing left
is the calling conventions to use.
Anyhow: At least with C, you can use libraries from different compilers "most
of the time"...
> I wouldn't do that. Just include instructions on how the get the
> library. It's just like any other fortran lib.
Well, I am still learning in the Fortran field... and NetCDF is the first
external lib I try to use from Fortran. Comparison to others is lacking:-/
> If the library needs to be available on a number of
> machines, just compile it and stick it on a network share.
> > Would such an "educated header" package be feasible? I really think
> the problem is that the module file format is not standardised.
I was speaking of a common source file, actually. To be compiled with the
compiler you are currently using.
The same way as the Fortran 77 interface (if I understand it correctly).
If the binary is not portable, but the source is, then use the source.
Instead of the .mod file, NetCDF could construct one big source file for
Fortran 90 that creates the interface module when compiled in the local source
tree.
I see that it makes sense to keep the Fortran 90 interface code distributed in
several files for development, though.
But then, I can try to locate other Fortran 90 libraries (people around here
don't seem to use many) and see what's "the standard way".
> think this is one of the greatest omissions of the Fortran standard.
> But then different compilers produce incompatible object codes
> anyway. So it wouldn't be that helpful.
Let's face it: There is no real standard for making compiler-portable libraries
for languages compiled to native code.
It just happens to work most of the time with C, and about never with C++ or
Fortran 90.
You have classes in Java, modules in Perl .. that would work, but funnily there
are not so (m)any different Perl interpreters to choose from, compared to the
choice you have with C/Fortran.
> I guess the reason why it
> works for C binaries (on Linux) is that they are so fundamental that
> if different compilers were incompatible you would need to recompile
> the entire stack.
My example with mpg123 includes MS Windows as platform, with mixing MinGW and
MSVC compilers. Generally, there are companies distributing (and making lots of
money from...) binaries of their programs compiled with different C compilers.
When C++ is involved in the interface to external libraries, you see them
offering builds compatible with the system C++ compiler (different Opera
packages for GNU/Linux with different gcc versions). But at least basic C
libraries are used from the OS, disregarding different compilers, IMHO (and of
course I am a bit weary on the question of stack alignment issues but it seemed
to work so far also with glibc builds).
> The trick is to install fortran libraries into compiler-arch dependent
> locations.
So... there we are again. Since I copy my around between different systems a
lot, it might be less of an inconvenience to actually ditch the Fortran 90
interface and use the Fortran 77 interface include file instead.
Just like I used the NetCDF C API in C++. But there it was because of some
strangeness/problems of me understanding the C++ API, not because of binary
incompatibility ... I didn't think that far, back then.
In the end, one might ask why one needs differing compilers on one system. But
well, for one it is the disturbing amount of compiler bugs I encounter in
Fortran (few people seem to actually use (more modern parts of) the language),
prompting me to quickly build with a different compiler (gfortran instead of
ifort, for example) to check if it's not just some obscure construct in my code
and not a compiler fault.
Also, I should inquire on what compiler has been used for NetCDF on one of our
Linux systems... it's neither the installed gfortran, nor the ifort:-/ Given
that, I suspect, though many people are working with Fortran here, external
Fortan 90 libraries do not seem to be a big issue.
Perhaps the Fortran 90 manual for NetCDF should contain a hint on that issue...
or does it already?
Alrighty then,
Thomas.
--
Dipl. Phys. Thomas Orgis
Atmospheric Modelling
Alfred-Wegener-Institute for Polar and Marine Research
