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 Ward, Allen >>> Building NetCDF statically is already an option, by passing >>> -DBUILD_SHARED_LIBS=OFF during configuration. Ward, this seems not to be working with the current release candidate netcdf-4.3.1-rc2 (it was working for netcdf-4.3.0) I tried cd build cmake -C ../cmake/ConfigUser.cmake -D"BUILD_SHARED_LIBS=OFF" -D"ENABLE_DLL=OFF" -D"HDF5_INCLUDE_DIR=I:\hdf5-1.8.11\src" -D"HDF5_LIB=I:\hdf5-1.8.11\build\bin\Debug\hdf5_D.lib" -D"HDF5_HL_LIB=I:\hdf5-1.8.11\build\bin\Debug\hdf5_hl_D.lib" -D"ZLIB_INCLUDE_DIR:PATH=I:\zlib-1.2.5" -D"ZLIB_LIBRARY:FILEPATH=I:\zlib-1.2.5\build\bin\Debug\libzlib_D.lib" -D"SZIP_INCLUDE_DIR:PATH=I:\szip-2.1\src" -D"SZIP_LIBRARY:FILEPATH=I:\szip-2.1\build\bin\Debug\libszip_D.lib" -D"ENABLE_DAP=ON" -D"CURL_LIBRARY=J:\curl-7.29.0\builds\libcurl-vc10-x86-debug-static-ipv6-sspi-spnego-winssl\lib\libcurl_a_debug.lib" -D"CURL_INCLUDE_DIR=J:\curl-7.29.0\builds\libcurl-vc10-x86-debug-static-ipv6-sspi-spnego-winssl\include" .. and the generated projects were all runtime library Multi-threaded Debug DLL (/MDd) Allen, on the other hand, I managed to make the generated projects by HDF5 CMake all runtime library Multi-threaded Debug (/MTd) by using this post http://www.cmake.org/pipermail/cmake/2006-July/010121.html and using the code in CMakeLists.txt I tried the same code in CMakeLists.txt of netCDF, but it did not make the substitution from /MD to /MT Is the next HDF5 version going to include the option -D"BUILD_SHARED_LIBS=OFF", like netCDF does now ? Pedro ------------ pvicente@xxxxxxx Department of Earth System Science 3200 Croul Hall University of California, Irvine Irvine, CA 92697-3100 ----- Original Message ----- From: Ward Fisher To: Pedro Vicente Cc: netcdfgroup@xxxxxxxxxxxxxxxx ; Allen D Byrne Sent: Wednesday, June 05, 2013 9:36 AM Subject: Re: [netcdfgroup] Make the Cmake Windows build static please ! Good morning Pedro, Building NetCDF statically is already an option, by passing -DBUILD_SHARED_LIBS=OFF during configuration. This will build the netcdf libraries and utilities statically, avoiding the direct dependency on MSVCR100.dll. They will, however, still inherit any downstream .dll dependencies from the curl, hdf and zlib libraries. You might be able to work around this by downloading (or building) static versions of these libraries. However, when I first investigated this process some months ago, it became obvious that this would require more time and effort on our end than we can reasonably expend (particularly for 64-bit versions of the libraries). Hence, we only provide shared libraries pre-built :). On a tangental note, I see from the NCO discussion you linked that your user was able to resolve the issue by removing the MSVCR100D.dll from the c:\nco\ directory. On Windows, it is preferable to use the Release version of the netcdf libraries (dependent on MSVCR100.dll) for the time being, due to cross-dll memory management situations which arise between the netcdf and hdf libraries. This is a known issue which can be followed in our JIRA system at https://bugtracking.unidata.ucar.edu/browse/NCF-220 . It is possible to build and use the debug libraries, but running the unit tests will result in a handful of errors. I hope this clarifies the difficulty faced in providing purely static libraries for netcdf-4/DAP enabled builds; as always, I am open to suggestions and work-arounds! Have a great day, -Ward On 6/5/13 12:24 AM, Pedro Vicente wrote: Hi Allen, Ward I have a request regarding your new CMake Windows build system, could you add an option to make the build static regarding the Microsoft libraries (MSVCR100D.dll) ? Starting with version 4.3.1, NCO http://nco.sourceforge.net/ uses the HDF5 and netCDF Windows libraries made with your CMake system, and this is causing problems for NCO users, as explained here https://sourceforge.net/projects/nco/forums/forum/9830/topic/8345151 and here https://sourceforge.net/projects/nco/forums/forum/9829/topic/8417103 This is just a matter of changing the compiler flag to /MT(d) http://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx Using a dynamic build is just a bad idea, because of these DLL issues. I have some Windows executables from code I did in the early 90's , that unfortunately I cannot run today, just because I linked them with DLLs, with the DLLs from the Visual Studio from that time, that do not exist anymore (it seems every new version they change the Visual Studio Dlls). Because of this I do not use Dlls, I know that eventually something will go wrong :-) Pedro ------ Pedro Vicente, Earth System Science University of California, Irvine http://www.ess.uci.edu/ ------------------------------------------------------------------------------ _______________________________________________ netcdfgroup mailing list netcdfgroup@xxxxxxxxxxxxxxxx For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
netcdfgroup archives: