Using HDF5 lib with Visual Studio

During October last year, my work involved using HDF library with FORTRAN and C and use them to store mounds of data other systems were generating.

The first step was to use the library with visual studio 2008 in windows. Companywide HDF5 had many users in Linux cluster but no formal implementation was available to use in visual studio. While that made the library available but building, a program using them in visual studio was a different matter. I faced couple of issues and with much googling and stack overflowing, solved them, here is the running note I took for one of the issue, just in case someone else is in the same situation.

Hope this helps.

1>libhdf5.lib(H5I.c.obj) : error LNK2001: unresolved external symbol _forceCRTManifestCUR

1>libhdf5.lib(H5.c.obj) : error LNK2001: unresolved external symbol _forceCRTManifestCUR

1>libhdf5.lib(H5D.c.obj) : error LNK2001: unresolved external symbol _forceCRTManifestCUR

1>libhdf5.lib(H5F.c.obj) : error LNK2001: unresolved external symbol _forceCRTManifestCUR

1>libhdf5.lib(H5S.c.obj) : error LNK2001: unresolved external symbol _forceCRTManifestCUR

From: https://social.msdn.microsoft.com/Forums/vstudio/en-US/af6796af-a1bf-4904-9923-15101956d882/linking-error-with-vc9-error-lnk2001-unresolved-external-symbol-forcecrtmanifestcur?forum=vcgeneral

• The various header files associated with the visual C++ runtime embed a number of directives into the compiled code. This power used to be used for good: appropriate #pragma’s could ensure that the resulting .lib file automatically had a dependency on the correct runtime libraries.
  

  However, a kind of dependency ____ comes about when one tries to mix projects built with different build settings in the same version of dev studio, and becomes even worse when pre-built libs made by another version of Dev Studio are used.
  

  The best thing to do, frankly, would be to rebuild your .libs in the same version of Dev Studio. There are some project settings that can be used when building a .lib that can ‘sanitize it’ a bit and make it’s use more compatible with different versions of dev studio – libraries should generally be built with the multi threaded runtime selected (NOT the DLL runtime) and the option “Omit Default Library Names” selected.
  

  In this case, __forceCRTManifestCUR, is a result of a #pragma comment(linker, “/INCLUDE=__forceCRTManifestCUR”) directive in one of the c-runtime header files.
  

  You can work around this by simply including a like like this in your main.cpp file:
  

  int __forceCRTManifestCUR=0;
  

  Doing this will “defeat” an attempt by the headers to get a manifest dependency to the “current” version of the CRT dlls embedded – but don’t worry – the correct CRT manifest is already specified correctly using a different mechanism, so you can generally quite safely define this symbol (by declaring it as an int or anything really) without causing any problems for the project.