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.
>I don't understand why one would want to make libnetcdf into a shared >library.... There are several reasons to use shared libraries: 1. Disk space savings. While netCDF is not huge, each executable will shrink some and this can add up to significant disk space savings; particularly if you have many applications that use netCDF. 2. Link times decrease. Again, since netCDF is not huge, time savings in the link stage are not dramatic. At least a small time decrease. 3. Memory space savings. Code that is common is put in a read-only psect and is shared amongst active processes. While the total code in netCDF is not huge, if you have many simultaneous processes using netCDF, the memory savings can be significant. You mentioned a disadvantage of "fragility" of executables since they are dependent on the state of the library. This is certainly true, but can be mitigated by careful maintenance of the library. With a properly constructed library, it is possible to upgrade netCDF to a new version (assuming backward code compatability) and have old executables automatically use the new version without relinking.
netcdfgroup archives: