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.
Hi Ed, > Starting with the next release, netCDF will build shared libraries by default. > ... > This may cause some problems with user makefiles and builds, and I regret that > extremely. But in the long run, it is best if the netCDF build system does things the > "usual" way. That's good news. It's going to be yet another culture shift for the netcdf community though. --- Stephen Pascoe +44 (0)1235 445980 British Atmospheric Data Centre Rutherford Appleton Laboratory -----Original Message----- From: Ed Hartnett [mailto:ed@xxxxxxxxxxxxxxxx] Sent: 13 September 2010 15:42 To: Pascoe, Stephen (STFC,RAL,SSTD) Cc: netcdfgroup@xxxxxxxxxxxxxxxx Subject: Re: [netcdfgroup] Linker option ordering when linking to HDF5 <stephen.pascoe@xxxxxxxxxx> writes: > Thanks Cedric and Mario, > > Apart from demonstrating that my C/C++ is a bit rusty ;-), I think > there is a take-home message here. Linking code against NetCDF has > got a lot more complex with NetCDF4. The excellent documentation > would be further improved with tips on compiling and linking. There is some here: http://www.unidata.ucar.edu/software/netcdf/docs/netcdf-install/Linker-F lags.html#Linker-Flags > > If this can be done I'd also recommend pointing out the usefulness of > -fPIC. I often find NetCDF libraries are installed statically without > position-independent code. This makes them unsuitable for wrapping > inside dynamic libraries used in dynamic language bindings: e.g. CDAT > and netcdf4-python > > Thanks, > Stephen. Yes, but please turn on shared builds with configure's --enable-shared option. Starting with the next release, netCDF will build shared libraries by default. This will simplify the linking process for complex builds. To get static libraries, you will have to use --disable-shared. This means that you must either install netCDF in one of the paths searched by your linker, or set environment variable LD_LIBRARY_PATH (for Linux) to point to the install directory, or in some other way tell the linker where the shared library can be found. Another consequence of the shared build is that the fortran library must be build separately from the C library. For static builds, the Fortran 77 and C libraries could both be found in libnetcdf.a. With shared builds, fortran users have to link to libnetcdff.a instead. (Note the extra "f" at the end.) This may cause some problems with user makefiles and builds, and I regret that extremely. But in the long run, it is best if the netCDF build system does things the "usual" way. Thanks, Ed -- Ed Hartnett -- ed@xxxxxxxxxxxxxxxx -- Scanned by iCritical.
netcdfgroup archives: