Applications using dynamic plugins must link to shared HDF5 library

[planetmarshall]

Summary

Applications using dynamic plugins must link to shared HDF5 library. API calls from the plugin fail if the application loading the plugin links to the static library

Steps to reproduce

See the attached minimal sample:

plugin_test.tar.gz

mkdir build
cd build
cmake ..  -DH5_PLUGIN_BUILD_SHARED=OFF
cmake --build .
export HDF5_PLUGIN_PATH=$(pwd)/plugins
./h5_plugin_test

Expected results

Test executable should exit cleanly with the following output:

filter is available for encoding and decoding.
....Create dataset ................
Chunk dimensions are 4X8....Writing compressed data ................

Actual results

filter is available for encoding and decoding.
....Create dataset ................
HDF5-DIAG: Error detected in HDF5 (1.12.1) thread 0:
  #000: ../src/H5S.c line 970 in H5Sget_simple_extent_dims(): not a dataspace
    major: Invalid arguments to routine
    minor: Inappropriate type
Error getting dimensions
...
#015: ../src/H5Z.c line 773 in H5Z__prelude_callback(): error during user callback
    major: Data filters
    minor: Error from filter 'set local' callback
failed to create dataset.

Workaround

Configure as above but link the shared HDF5 libraries with

cmake ..  -DH5_PLUGIN_BUILD_SHARED=ON

Notes

If this is expected behaviour I could not locate it in the documentation.

[planetmarshall]

Note that this is also the case for the HDF5 tools, eg h5repack-shared can be used with a dynamic plugin whereas h5repack rasies the same error as above.

[byrnHDF]

HDF5 using dynamic plugins use the dlopen call, which must use shared libraries. Otherwise application will use an incorrect instance of the hdf5 library.

[planetmarshall]

HDF5 using dynamic plugins use the dlopen call, which must use shared libraries. Otherwise application will use an incorrect instance of the hdf5 library.

Yes that makes sense, thanks - though I do think the documentation needs to be clearer on this point (I'm happy to contribute that documentation once I've finished work on this plugin).

This limitation also only applies to plugins that call back into the HDF5 API - not all of them do, notably the bzip2 sample plugin.

If the plugin callback signatures were extended to make calling back into the API unecessary (eg by providing chunk size and type information), this limitation could be mitigated.

[byrnHDF]

The documentation needs to fixed in hdf5. And the plugins repo as well.

This limitation also only applies to plugins that call back into the HDF5 API - not all of them do, notably the bzip2 sample >>plugin.

NO, this limitation applies always when using plugins and needs to be documented.
When building plugins, the hdf5 library used to build can be static (shared still has advantages across platforms) under very limited conditions. If there are no calls back into the library, there might be a reason, but not recommended. The actual plugin must be a shared module.