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