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.
