The  'build-VS2013-64.bat' is a simple call to a script to build the most 
common version of the library, it can be edited to use other options. However 
the best solution is to use the CTestScript.cmake file with a parent ctest 
script as described in the documentation.

Secondly, the CMake process for HDF5 does have a UserMacros.cmake option to 
allow using static C libs. Also documented.

If there is any confusion or suggestions for better describing the above 
documentation, please let us know how to improve the documentation.

Allen Byrne

On Thursday, September 22, 2016 2:16:21 AM CDT wrote:
> My issue is related to the one presented by Terry McKiernan on 06Mar2016 at 
> It is similar in that I was getting exactly the same six 'unresolved symbol' 
> link errors when I tried building my own C++ code using the libhdf5.lib, 
> libhdf5_cpp.lib, libzlib.lib, and libszip.lib libraries that are in 
> that are available for download from 
> ''. 
> Likewise, when I downloaded the HDF5 v.1.8.17 repository and used CMake build 
> the libraries locally, I ran into the same problem.
> But my issue is also very different in that my objective is to create 
> executable code that is statically linked and for that I need complete and 
> truly static HDF5 libraries.
> There are two points I'd like to make:
> 1) This is my first experience with CMake so I may be doing something wrong. 
> However, it seemed reasonable to me that replacing '-C Release' on the 
> 'ctest' command line with '-C Debug' should create libraries of the Debug 
> variety. It didn't -- only Release libraries. And only static Debug libraries 
> can link to a Debug executable.
> 2) Although the libraries built by running 'build-VS2013-64.bat' suffered the 
> same problem as the downloadable libraries, a beneficial side effect is the 
> creation of a VS2013 solution file that I can open and modify easily in the 
> VS2013 GUI. When I did so, I noticed that the 'hdf5.lib' and 'hdf5_cpp.lib' 
> projects were set up to generate code using shared libraries (e.g., 
> 'Multi-threaded Debug DLL (/MDd)' switch) rather than static libraries (e.g., 
> 'Multi-threaded Debug (/MTd)' switch). This was the problem. By changing 
> these switches to the static ones I was able to build complete and truly 
> static libraries that were fully usable for building statically linked Debug 
> and Release executables from my own C++ code that makes HDF5 calls.
> I wasn't expecting it to be so hard to write a statically linked version of 
> my code. It took much more time than should have been necessary. I put this 
> information out there in the hope that the HDF5 developers will endeavor to 
> make sure that in future releases the CMake scripts and downloadable binaries 
> advertised as providing static HDF5 libraries do not exhibit the flaws I 
> encountered.
> John Ottusch
> _______________________________________________
> Hdf-forum is for HDF software users discussion.
> Twitter:

Hdf-forum is for HDF software users discussion.

Reply via email to