[MDAL-Developer] Compiling with HDF5 1.10

Peter Petrik peter.petrik at lutraconsulting.co.uk
Wed Oct 21 03:22:13 PDT 2020


Yeah, I haven't  tested  with  that version. Best  to create a ticket so we
can look at it later. I think that we  may even add a windows build based
on conda to the MDAL repo, if you like to do so.
For GDAL dependency, we want to remove it, but first we need to implement
GRIB and NetCDF drivers without need of GDAL.

Peter

On Wed, Oct 21, 2020 at 11:58 AM Paul Harwood <runette at gmail.com> wrote:

> Heho
>
> I am compiling through a GH Action - which you can see for yourself here :
>
>
> https://github.com/ViRGIS-Team/mdal-upm/blob/main/.github/workflows/winbuild2.yml
>
> IMPORTANT NOTE - before you say. This action CURRENTLY has the
> -DWITH_HDF5=OFF. That is so it works despite this issue. If it were not to
> have this flag then one would see the error messages I mentioned.
>
> Also :
>
> - I know this is always a clean environment because - GH Action.
> - This is VERY DEFINITELY compiling against a different version of HDF5
> since I am building against the conda repo of GDAL 3.1.3 and not the
> OSGEO4W repo. Sorry, I thought I made that clear in the title.
>
> As far as I am aware the conda repo uses HDF5 1.10.6 and the OSGEO4W repo
> seems to use 1.8.14 (or 1.8.11 in the choco repo).
>
> I know this is NOT the MDAL supported version - but it is the current
> "preferred" build for GDAL and - since the latest HDF5 version is 1.12,
> using 1.8 does seem very backward. QGIS and MDAL probably need to grapple
> with this at some point.
>
> However - it seems that there are some compile-time changes needed after
> 1.8.14. I just wondered if anyone had already solved this?
>
> In the short term - for us compiling without HDF is not a huge issue. And
> - I guess we will have to get around to solving it sometime.
>
> Br
> P
>
> On Wed, 21 Oct 2020 at 08:38, Peter Petrik <
> peter.petrik at lutraconsulting.co.uk> wrote:
>
>> Hi Paul,
>>
>> can you please post here your CMAKE command you use to generate the build
>> system and the output of the command.
>> Also make sure you start from the empty build directory when running it.
>> This looks like you are linking against wrong version of hdf5 library.
>>
>> Peter
>>
>>
>> On Tue, Oct 20, 2020 at 9:18 PM Paul Harwood <runette at gmail.com> wrote:
>>
>>> I am not sure this is a bug as such - so I thought I would try out the
>>> new mailing list before raising as an issue.
>>>
>>> For various reasons - I am trying to compile MDAL against the current
>>> conda version of GDAL - 3.1.3 - and the conda versions of the deps.
>>>
>>> It is mostly working - pace the testing issues I have raised. However I
>>> get a fatal error (shown below) when compiling against HDF5 - which in this
>>> case is v1.10.6.
>>>
>>> This appears to be a known issue - for instance here
>>> https://github.com/conda-forge/gdal-feedstock/issues/25 and other
>>> mentions. There seems to be a need for a compiler definition or flag and I
>>> have tried playing with this - but nothing works.
>>>
>>> Does anyone have any idea of what I need to do? Or where to put the
>>> compiler definition?
>>>
>>>
>>> mdal_hdf5.obj : error LNK2001: unresolved external symbol H5T_C_S1_g
>>> [C:\Users\runes\Documents\GitHub\MDAL\build\mdal\mdal.vcxproj]
>>> mdal_hec2d.obj : error LNK2001: unresolved external symbol H5T_C_S1_g
>>> [C:\Users\runes\Documents\GitHub\MDAL\build\mdal\mdal.vcxproj]
>>> mdal_hdf5.obj : error LNK2001: unresolved external symbol
>>> H5T_NATIVE_INT_g
>>> [C:\Users\runes\Documents\GitHub\MDAL\build\mdal\mdal.vcxproj]
>>> mdal_flo2d.obj : error LNK2001: unresolved external symbol
>>> H5T_NATIVE_INT_g
>>> [C:\Users\runes\Documents\GitHub\MDAL\build\mdal\mdal.vcxproj]
>>> mdal_hec2d.obj : error LNK2001: unresolved external symbol
>>> H5T_NATIVE_INT_g
>>> [C:\Users\runes\Documents\GitHub\MDAL\build\mdal\mdal.vcxproj]
>>> mdal_hdf5.obj : error LNK2001: unresolved external symbol
>>> H5T_NATIVE_FLOAT_g
>>> [C:\Users\runes\Documents\GitHub\MDAL\build\mdal\mdal.vcxproj]
>>> mdal_flo2d.obj : error LNK2001: unresolved external symbol
>>> H5T_NATIVE_FLOAT_g
>>> [C:\Users\runes\Documents\GitHub\MDAL\build\mdal\mdal.vcxproj]
>>> mdal_hec2d.obj : error LNK2001: unresolved external symbol
>>> H5T_NATIVE_FLOAT_g
>>> [C:\Users\runes\Documents\GitHub\MDAL\build\mdal\mdal.vcxproj]
>>> mdal_hdf5.obj : error LNK2001: unresolved external symbol
>>> H5T_NATIVE_DOUBLE_g
>>> [C:\Users\runes\Documents\GitHub\MDAL\build\mdal\mdal.vcxproj]
>>> mdal_flo2d.obj : error LNK2001: unresolved external symbol
>>> H5T_NATIVE_DOUBLE_g
>>> [C:\Users\runes\Documents\GitHub\MDAL\build\mdal\mdal.vcxproj]
>>> mdal_hdf5.obj : error LNK2001: unresolved external symbol
>>> H5T_NATIVE_UINT8_g
>>> [C:\Users\runes\Documents\GitHub\MDAL\build\mdal\mdal.vcxproj]
>>> C:\Users\runes\Documents\GitHub\MDAL\build\mdal\Debug\mdal.dll : fatal
>>> error LNK1120: 5 unresolved externals
>>> [C:\Users\runes\Documents\GitHub\MDAL\build\mdal\mdal.vcxproj]
>>>
>>> _______________________________________________
>>> MDAL-Developer mailing list
>>> MDAL-Developer at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/mdal-developer
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mdal-developer/attachments/20201021/617767b9/attachment.html>


More information about the MDAL-Developer mailing list