Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Russ,That explains why I didn't see an "ff" library. I decided that it was not worth using shared libraries for our cluster; the compiles are done on the front end and the jobs run on compute nodes. I would have to create and maintain libso/libso64 directories on every compute node (which I do for the compilers libso/libso64 redistributables).
I compiled completely separate netCDF libraries for every OS/compiler combination. I found that not only the lib directory files were different, but the Fortran 90 modules were different, at least between the 32-bit and 64-bit versions. Thus, the usual practice of a single include directory and separate lib and lib64 library directories does not work.
Larry Baker US Geological Survey 650-329-5608 baker@xxxxxxxx On Aug 13, 2010, at 11:54 AM, Russ Rew wrote:
Larry Baker wrote: ...My build does not have a library named libnetcdff.a, so I'm not sure if we are configuring netCDF the same way:Starting with version 3.6.2, building separate Fortran libraries was required for shared library builds. In previous releases, the C andFortran functions were in the same static library. In current releases, when you enable shared libraries an additional library, libnetcdff (note the extra "f"), contains the Fortran-77 and Fortran-90 functions. Thisextra Fortran library is built when either --enable-shared or --enable-separate-fortran are specified as configure options. Using --enable-shared automatically turns on --enable-separate-fortran. One reason you may want to use the --enable-separate-fortran option is to support multiple netCDF Fortran libraries for different Fortran compilers. --Russ
netcdfgroup
archives: