NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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
netcdfgroup archives: