> Russ: First, thank you very much for your time. I got ModelE to link > properly after uninstalling all NetCDF then building NetCDF v3.6 on my > machine. I noticed that the libraries (or whatever you call the stuff > that gets put into the "lib" folder) seem have a different naming > convention: in 3.6 the names have the extension .a and .la, whereas in > version 4.x they have what I think are more common extensions of .so, > .so.0, etc. I think this is why ModelE would not build - it was looking > for the .la or .a extensions for the shared libraries. Can you verify > my summary? Also, I *think* it's possible to handle this by making > symlinks such as libnetcdf.a -> libnetcdf.so.0 - but I'm not sure which > libraries correspond. There is libnetcdf.a and libnetcdf.la in v3.6 but > libnetcdf.so and libnetcdff.so in v4.x Up until netCDF 4.1.3, the default was to build static libraries instead of shared libraries. On Unix systems, static libraries have extensions such as ".a" (for "archive") and ".la" (for "libtool archive"). Shared libraries have extensions such as ".so" (for "shared object"), as well as version information appended. It's not possible to just make a symlink to hide the difference. Static libraries and shared libraries are quite different, each with advantages and disadvantages. For a brief summary, see the first answer here: http://stackoverflow.com/questions/2649334/difference-between-static-and-shared-libraries For netCDF-4, one advantage to using shared libraries is that it often makes linking simpler. For example, if the netCDF Fortran library is installed in /usr/local/lib/libnetcdff.so (a symbolic link to a numbered version), you can use it with a Fortran application by just supplying the library arguments ... -L/usr/local/lib -lnetcdff and the other libraries that it depends on are automatically linked when needed. However, if you're using static libraries, you typically need to mention the other dependent libraries when linking, with something like: ... -L/usr/local/lib -lnetcdff -lnetcdf if the Fortran and C libraries are separate (as they are with netCDF-4) or even longer invocations if you're using netCDF-4 features such as compression. Maybe netCDF-3.6.3 will work for you, if you don't encounter any of the issues and problems fixed since it was released. Many of those have to do with support for large files and large variables (e.g. larger than 2 GBytes). --Russ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: UBO-194263 Department: Support netCDF Priority: Normal Status: Closed
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.