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.
"Mark Rivers" <rivers@xxxxxxxxxxxxxxxxx> writes: > Hi Russ, > > > > I am puzzled on how to proceed with this. You recommend that I run 4.1.3, > but my problem is specifically on Windows with the Microsoft VS > compiler. Unfortunately we cannot support every different compiler - we don't have the resources. We are building 32-bits DLLs via mingw32 on Linux, and you can get a recent copy of the C DLL here: ftp://ftp.unidata.ucar.edu/pub/netcdf/snapshot/netcdf4_dlls_vs.zip There are some difficulties to supporting the mingw32 build, but in general it works well, building from our configure.ac and Makefile.am files without requiring that we maintain a separate build system. Another alternative we have considered in CMAKE, which is used by the HDF5 group. The CMAKE system involves some separate build system business, but also reuses what is already specified in the primary build system. So even if we were to abandon mingw32, we whould move to CMAKE, not visual studio. The reason is simple: we don't have the resources to track our changes to the codebase into visual studio, and to keep up to date with Microsoft's new releases (which invariably break whatever existing build system we have). There are many changes underway in the netCDF codebase, as explained here: http://www.unidata.ucar.edu/blogs/developer/en/entry/refactoring_of_the_netcdf_architecture Maintaining a netCDF build in visual studio would not be too difficult for any programmer who wished to contribute and also gain undying glory. (Hint, hint.) Our code is on an open subversion repository, and we are using an open bug tracking application which gives users a close look at what we are doing on a day-to-day basis: https://www.unidata.ucar.edu/jira/browse/NCF We invite collaboration and welcome contributes to our project. > What is your suggestion as to how to build with VS on 4.1.3? If you wish to use visual studio you must put together your own build system. The best way to do this would be to start with a cygwin build on the same system (i.e. using the netCDF provided configure script and makefiles), and then look at what commands are run on which files to put together the visual studio build. The Makefile.am files contain lists of all the relevant code files. > > > > I do build my application with Cygwin, but I also need to build with VS, > because there are many detector drivers that do not build correctly with > Cygwin, they require VS. So I need to build my application with both > compilers. > > > > Note that I am not using the VS development environment, I am using > gnumake. But I am invoking the VS compiler and linker. > Then can you not use our configure and build with vs under cygwin? > > Can anyone answer the question as to whether netCDF 3.6.3 with Windows VS > can correctly write classic netCDF files with sizes >2GB, as Linux and > Cygwin can? > It's very likely that the 3.6.3 build on windows linked to a 32-bit lseek, and a 64-bit lseek is required to go beyond the 2 GiB boundary. I note this piece of history, commented out of netcdf.h: /*#define lseek _lseeki64 #define off_t __int64*/ Perhaps undefining these and recompiling will help. But that would still not address the other bugs that have been fixed in the classic library since the 3.6.3 release. Thanks, Ed -- Ed Hartnett -- ed@xxxxxxxxxxxxxxxx
netcdfgroup archives: