I have downloaded the hdf5-1.12.0-Std-win10_64-vs14 and it looks like its binaries are for RELEASE:
When I try to with it in DEBUG I get many errors like this:
4>libhdf5_cpp.lib(H5Exception.obj) : error LNK2038: mismatch detected for ‘_ITERATOR_DEBUG_LEVEL’: value ‘0’ doesn’t match value ‘2’ in main.obj
4>libhdf5_cpp.lib(H5Exception.obj) : error LNK2038: mismatch detected for ‘RuntimeLibrary’: value ‘MD_DynamicRelease’ doesn’t match value ‘MDd_DynamicDebug’ in main.obj
Is there a simple solution?
Note that I do not need to debug HDF5 itself just use it when linking to a DEBUG configration build of mu app.
Thanks.,
I do have the very same problem, although with an older version of the libraries. The *.pdb files don’t help at this point, as the build fails - so nothing to debug…
Is there maybe a compiler switch I missed or do I have to build the HDF5 librieres in debug configuration myself (which I would like to avoid)?
So to state the problem - you want to build your application with debug and link with the release (+debug pdb) version of the hdf5 library. Are you using CMake? CMake understands RelWithDebInfo, with which you can use the debugger.
Yes, I want to build my application with WS2017 in debug configuration (but no need to debug the HDF5 libraries) and link with the release version of the hdf5 library. Unfortunately I do not use CMake. Build fails with lnk errors of type ‘_ITERATOR_DEBUG_LEVEL’: value ‘0’ doesn’t match value ‘2’ in *.obj. for the hdf5 libraries.
I don’t have any problems building the application in release configuration - but then I can’t debug…
Unfortunately, the only solution I know on windows is that you need to have a debug version of the hdf5 library.
You would need to build it.
Another possibility, is to duplicate the settings of the CMake RelWithDebInfo configuration for your application and create *.pdb files for debugging.
The problem is most likely in mismatched runtimes. I’m less familiar with C++, but C standard library state is managed in the CRT dlls on Windows, which can cause problems if, say, a library allocates memory in the release CRT and frees it in the debug CRT. I wouldn’t be surprised if C++ standard library state had similar problems.
As Allen said above, your best bet is probably going to be to build a debug version of the library and link to that when building your own software in debug mode.
As Dana and Allen state there is a mismatch between the Release and Debug runtime C/C++ libraries on your system. You should take the warning VERY seriously. There are 2 ways to fix. Build your application in RelWithDbgInfo and debug that way but there is a reasonable chance that certain parts of your code will be optimized away by the compiler. Or build HDF5 yourself using CMake and Visual Studio and use the produced debug versions of the HDF5 libraries to link your application to.
I cannot overstate this enough on Visual Studio. DO NOT MIX RELEASE and DEBUG runtime libraries. It is a recipe for disaster. All sorts of subtle crashes will crop up and you will pull your hair out trying to solve them when it is really a clash between the C/C++ runtime libraries. This is a “thing” with Visual Studio but not macOS or Linux.
