NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Ward < Currently, using find_package(HDF5 NO_MODULE) results in Visual Studio attempting to link against the shared libraries (.dll) themselves, instead of the associated import libraries (.lib). I'm still trying to figure out why this is, exactly, but in the mean time I am using the work-around mentioned in your previous email. > Using find_package(HDF5 NO_MODULE) does not do this at all. If you find_package(HDF5) and allow the FindHDF5.cmake supplied with cmake to run, then it picks up the dll instread of the lib. I tried this on a new version of cmake and it appears to be a new 'bug' - but if you use the NO_MODULE approach then you use on the the hdf-config.cmake supplied when hdf5 is installed and this does not happen. If it is happening, then you need to go through your CMakeLists.txt and remove any ${HDF5_C_LIBRARY} type of references and instead just link to "hdf5", the target is defined as imported and all these errors go away. I presume this is the fix you are referring to. The trouble arises when you must support a cmake version of hdf5 (easy) and an old style non cmake install of hdf5, (pain in the arse). AFAICT there is a bug in the findhdf5.cmake supplied with cmake itself which reports all these libraries as HDF5_C_LIBRARY C:/Program Files/HDF5/bin/hdf5_D.dll Instead of HDF5_C_LIBRARY C:/Program Files/HDF5/bin/hdf5_D.lib (just tested with cmake 2.8.11-rc3 and hdf5 cmake branch from svn updated a few minutes ago) I'm CC'ing the cmake list and Will (the maintainer of the findhdf5) just in case they have some feedback that's useful. Looking at the findhdf5 module, it's not obvious to me where this value is set, so I won't attempt a fix (yet), but it'd be nice if we could get a fix into cmake before the next release- which is quite soon I guess since they're on rc3. JB
netcdfgroup
archives: