Ward
Build all statically.
NCO for Windows is built all statically, just to avoid users having to search
for dependency libraries (as well as DLL incompatibilities).
This goes for the libraries themselves (netCDF, HDF5, zlib, curl, antlr, gsl)
as well for the Windows C Run-Time libraries.
-Pedro
----------------------
Pedro Vicente
pedro.vicente@xxxxxxxxxxxxxxxxxx
http://www.space-research.org/
----- Original Message -----
From: Chris Barker
To: Ward Fisher
Cc: don.k.hooper@xxxxxxxx ; netcdfgroup@xxxxxxxxxxxxxxxx List
Sent: Thursday, November 13, 2014 2:36 PM
Subject: Re: [netcdfgroup] NetCDF-4 for Windows
On Thu, Nov 13, 2014 at 2:14 PM, Ward Fisher <wfisher@xxxxxxxxxxxxxxxx> wrote:
The pre-built netcdf binaries should work with those packages, so it would
be fine to refer people to those sites I think. However, the installer does
come bundled with the dependencies (libhdf5.dll, libcurl.dll, zlib.dll, etc)
that netcdf was built against.
great. However, could you statically link netcdf.dll against all of these,
and have one-stop, shopping, and less confusion? Sure, some folks will want to
use some of those libs independently, but they'll knwo how to build, etc
themselves.
while we're at it, a small plug for calling it netcdf4.dll -- or even better,
netcdf4.x.y.dll
yes, it's pretty cool that you can drop a netcdf4.dll on top of a
netcdf3.dll, and it should "just work", but you certainly can't do it the other
way around. And the fun of Windows "dill hell" makes that all too likely.
The issue people run in to is that these libraries live inside a directory
and need to be either manually copied into a folder on the system PATH or have
the folder added to the path.
When building out the packaging system, I was loathe to do either of these
automatically because I didn’t want to overwrite any pre-existing libraries, or
modify the system path. This is becoming a larger issue, however, so I should
probably revisit these decisions.
yeah -- this is a tough one Ideally:
The command line tools: ncdump, etc go somewhere on to the PATH.
The dlls go in the same dir, so that the command line tools will find them.
All good.
However, that means that those dlls are now on the Windows dll search path,
so other apps may suddenly find them instead of whatever copy they had been
using.
This, by the way, is the primary source of "dll hell" on windows: the
combination of:
a) the search path for executables and the dll is the same (WTF?)
AND
b) executable will look next to themselves for dlls first.
b) means that folks commonly put dlls next to executable,
a) means that that puts them on teh dll search path, which means any other
app might them.
sigh.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@xxxxxxxx
------------------------------------------------------------------------------
_______________________________________________
netcdfgroup mailing list
netcdfgroup@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
