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 12:47:28 +0100 schrieb Magnus Hagdorn <Magnus.Hagdorn@xxxxxxxx>: > Fortran libraries are a bit of a mess, especially f90 libraries since > as you observed the module files are compiler vendor and version > specific. I now realize that this seems to be a common problem between Fortran and C++. Both can somehow use C libraries since, at least for one OS (calling convention), those are compatible between compilers. But, you better think twice before writing a C++ library because every compiler is incompatible with itself and others... Java got a defined binary format, but somehow it did not encounter to C++ and Fortran 90 designers to care about interoperability of code. > them into /usr/lib/modules or so. if you want to use the intel > compilers than you will need to compile netcdf yourself Basically this means I need to include the NetCDF library into my model source. When there is no reliable external source to use, this dependency needs to be contained in my sources. To be sensible, only the part wrapping over the C library should be needed -- since you usually _can_ rely on the C library to work. And it would somehow be against the whole purpose of the NetCDF format and library to have a different copy of the whole thing in each software package that is using it. Now, perhaps that mess with Fortran libraries could be cleaned up when there is a nice package of the Fortran wrapper part (for use with NetCDF C API from some version up) that easily can be integrated in custom build systems (in an automated way). One should not rely on autoconf/make for that sub-package -- it should be enough to name the C API version to support, since all the platform specific details are handled in the C library (or not?). Would such an "educated header" package be feasible? I really think that this would be the correct approach, faced with the inconsistency of fortran runtime systems. Perhaps it would also work as an include file like the F77 interface, so that you'd have such a file in your source: module my_fortran_interface public ! Possibility to limit exported symbols. include "netcdf.f90" end module ...and all other codes would simply use my_fortran_interface (possibly with ONLY: statement, even). I would like to get a hint on the difficulties involved with that before I try to hack that myself... > BTW, I am > assuming you are using Linux or some other Unix like OS. Heck, what else? ;-) Alrighty then, Thomas. -- Dipl. Phys. Thomas Orgis Atmospheric Modelling Alfred-Wegener-Institute for Polar and Marine Research
netcdfgroup archives: