[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #UBO-194263]: netcdf fortran 4.2 build error

> 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:


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 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.