Fix for H5Literate() callback versioning

[derobins]

The netCDF library supports many versions of HDF5, which handles API compatibility via a set of API-call-specific macros. netCDF uses H5Literate(), which was versioned in the 1.12.x maintenance line in order to better support the virtual object layer (VOL).

h5_test/tst_h_files4.c failed to compile with certain compilers when the HDF5 library was built using pre-VOL versions of the library- e.g., 1.10, which can be configured with --with-default-api-version=110. This was due to the API compatibility macros being used to select the 1.10 version of H5Literate(), but not its callback function, which was set using a H5_VERSION_GE() macro that does not take the compatibility macros into consideration.

Fixing the problem involved removing the H5_VERSION_GE() macro and letting the compatibility macros handle the versioning, and using the H5_USE_XXX_API_DEFAULT symbols to protect the H5Oopen_by_addr() call used in the callback (a new call that wasn't versioned, hence the different protection mechanism).

Tested w/ HDF5's develop branch w/ both 1.14 and 1.10 API bindings

Fixes #2886 (4118 in HDF5's issue tracker)

[CLAassistant]

All committers have signed the CLA.

[WardF]

Thank you for the quick fix! It is strange that this did not manifest until recent versions of clang. Thanks!

[derobins]

clang must be fussier about function pointer signatures matching exactly.

I see we should probably have H5_API_VERSION_GE/LE macros as well...

[WardF]

Thanks!

[WardF]

Fixing the AppVeyor config to use HDF5 1.10.x; also will update the documentation to reflect this new requirement. It does not seem unreasonable to need to drop support for 1.8.x at this point.

[derobins]

I'll have a fix for this in a second. I didn't realize 1.8 never had a H5_USE_18_API_DEFAULT symbol defined.

[derobins]

As for 1.8 in AppVeyor, we no longer support any version of the library earlier than 1.14, so people should try to upgrade. Security fixes, build system improvements, etc. will not be heading downstream to unsupported branches.

[WardF]

Thanks! We are moving away from appveyor (as mentioned during our call :)) so I'm not worried about that too much, we'll modernize in the Windows-based github action; our *nix-based testing already uses a matrix of modern HDF5 versions :)