Hello Pedro,
On 9/17/13 10:10 PM, Pedro Vicente wrote:
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)
Can you be a little more specific about how this does not work? I was
able to build the netCDF-C libraries statically using the latest
developer snapshot and Visual Studio 10, with the resultant netcdf.lib
file being a proper 'ar' archive. All tests ran properly.
Is the issue that the generated projects are configured to use the the
dynamic instead of static CRT? This is as it was in the netcdf-4.3.0
libraries, so if that was working for you I suspect this will as well.
However, looking at the relevant CMake documentation,
http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_build_my_MSVC_application_with_a_static_runtime.3F
I see how this could be set as a user-configurable option when invoking
cmake. I will try to add this in and, assuming there aren't any
problems caused by using the static CRT, it will be an option available
in the upcoming netCDF-4.3.1-RC3. In the meantime, you can replace
'/MD' with '/MT' in the cache editor.
If I have misunderstood the issue, or if you are seeing an outright
error/unexpected behavior please let me know. Have a great day,
-Ward
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 <mailto:pvicente@xxxxxxx>
Department of Earth System Science
3200 Croul Hall
University of California, Irvine
Irvine, CA 92697-3100
----- Original Message -----
*From:* Ward Fisher <mailto:wfisher@xxxxxxxxxxxxxxxx>
*To:* Pedro Vicente <mailto:pvicente@xxxxxxx>
*Cc:* netcdfgroup@xxxxxxxxxxxxxxxx
<mailto:netcdfgroup@xxxxxxxxxxxxxxxx> ; Allen D Byrne
<mailto:byrn@xxxxxxxxxxxx>
*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/
