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.
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...) > > 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. > I wouldn't do that. Just include instructions on how the get the library. It's just like any other fortran lib. Are you going to distribute your code? If it is only in-house than you could include netCDF in your built. However, chances are that others will find it useful as well. If the library needs to be available on a number of machines, just compile it and stick it on a network share. > 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: > the problem is that the module file format is not standardised. I 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. 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. The trick is to install fortran libraries into compiler-arch dependent locations. > > > BTW, I am > > assuming you are using Linux or some other Unix like OS. > > Heck, what else? ;-) just making sure -- Magnus Hagdorn Specialist Computing Officer School of GeoSciences The University of Edinburgh Grant Institute West Mains Road Edinburgh EH9 3JW Scotland PHONE: (+44) 131 650 5894 FAX: (+44) 131 668 3184 email: Magnus.Hagdorn@xxxxxxxx The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
netcdfgroup archives: