Talking about the first of Gray's criteria for scalable Scientific Data Management Systems:
[Read More]1. Data independence: the physical data organization can change without breaking existing applications
Whats wrong with Fortran unformatted writes?
23 May 2011
Talking about the first of Gray's criteria for scalable Scientific Data Management Systems:
[Read More]1. Data independence: the physical data organization can change without breaking existing applications
NetCDF Fortran and C libraries file for permanent separation
22 April 2011
In the upcoming 4.1.3 release at the end of this Summer, there will be a permanent change in how the fortran library is packaged.
In olden times, before shared libraries came along, the netCDF F77 API was packaged up with the C library. This meant that the same binary .a file served as a library for both C and Fortran 77. This was a somewhat unorthodox method of proceeding, but it worked well for netCDF until shared libraries came along.
With shared libraries, the packaging of the F77 API with the C API has an odd side-effect: when compiling a C program, the linker wants to know where the fortran shared libraries are, even though there is no fortran code involved. Naturally we are not going to make our C users suffer this sort of indignity. After all, if they wanted to associate with Fortran riff-raff, they would not be C programmers!
To fix this, we introduced the --enable-separate-fortran option in configure. When turned on (and it was turned on by default for shared library builds) the fortran 77 API is packaged in a separate library. Fortran users now have to link to -lnetcdff -lnetcdf instead of just -lnetcdf. (Note the extra "f" on the fortran library name).
This works so very well that I am taking out all ability to build the fortran 77 and C library together. Starting in 4.1.3, a separate fortran library will always be built. The motivation for taking this feature out is to simplify the build system. There are numerous places where we have to do one thing for a combined library, and another for separate libraries. And this also doubles our test cases (although I don't actually check both build styles on all platforms anyway, as that would in impractical).
But as soon as I merge my branch into the trunk, this and some other configure options will go away, and the build system will be considerably simpler, which makes it easier to maintain and get correct on all platforms.
