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 'https://support.hdfgroup.org/HDF5/release/obtain5.html'.
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.
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.
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 'https://support.hdfgroup.org/HDF5/release/obtain5.html'.
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.
A followup on issue #1: There was a oversight when using the CTestScript.cmake file for building with the configuration type (-C Release/Debug) the wrong variable was being used. We are working on a solution.
Allen
···
On Thursday, September 22, 2016 9:12:31 AM CDT Allen Byrne wrote:
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 j4p9xevepa@snkmail.com wrote:
> My issue is related to the one presented by Terry McKiernan on 06Mar2016 at https://lists.hdfgroup.org/pipermail/hdf-forum_lists.hdfgroup.org/2016-March/009293.html.
>
> 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 'https://support.hdfgroup.org/HDF5/release/obtain5.html'.
>
> 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.
> Hdf-forum@lists.hdfgroup.org
> http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
> Twitter: https://twitter.com/hdf5
>
