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.
On Thursday, September 22, 2016 2:16:21 AM CDT j4p9xev...@snkmail.com 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
> hdf5-1.8.15-win64-vs2013-static.zip 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
> John Ottusch
> Hdf-forum is for HDF software users discussion.
> Twitter: https://twitter.com/hdf5
Hdf-forum is for HDF software users discussion.