[gdal-dev] compile error on windows

[Jeff McKenna]

It would be great for all those interested in this thread, to take a 
moment and make sure that these steps are documented in the BuildHints 
wiki page for this (https://trac.osgeo.org/gdal/wiki/HDF). I did that of 
course, but other community members should as well, especially all those 
so concerned with the HDF* process on Windows.

I agree, getting HDF5, HDF4, and NetCDF all to play nicely together is 
extremely difficult on Windows, but, if everyone going down these paths 
takes a moment to contribute back to the community by enhancing the wiki 
pages, things will go much more smoothly for everyone.

If you want to test all these formats working on Windows, give the 
latest MS4W builds a try (the builds with HDF*, NetCDF working are still 
marked as "experimental" at http://www.ms4w.com/release/experimental/). 
Feedback is welcomed.

-jeff


-- 
Jeff McKenna
MapServer Consulting and Training Services
http://www.gatewaygeomatics.com/



On 2016-08-01 8:19 PM, twhall wrote:
> I had previously built HDF5 v1.8.17 as a 64-bit DLL on Windows 10, Visual
> Studio 2010.
>
> Today I tried to rebuild GDAL v2.0.2 to include the HDF5 format, but failed
> with the undefined symbols as reported by Ryan Grout on Apr. 29.
>
> I followed his advice from May 02, to edit frmts/hdf5/makefile.vc, replacing
> -D_HDF5USEDLL_ with -DH5_BUILT_AS_DYNAMIC_LIB, and that fixed the immediate
> problem.  GDAL built successfully, though it remains to be seen whether the
> HDF5 part actually works.
>
> The dependence on -DH5_BUILT_AS_DYNAMIC_LIB originates in the HDF5 header
> H5api_adpt.h:
> #ifdef H5_BUILT_AS_DYNAMIC_LIB
>    ...
>    #define H5_DLL __declspec(dllimport)
>
> Without that, the symbols won't import from the DLL.
>
> I don't see any dependence on _HDF5USEDLL_
>
>