We did some more research and found a solution. The problem is in the H5PL__open() function in H5PL.c where it tries to load the plugin using the H5PL_OPEN_DLIB macro (dlopen() on Linux). This fails when our plugin is not linked with libhdf5, and adding a call to dlerror() to obtain the error message gives:
/usr/local/hdf5/lib/plugin/libh5rice.so: undefined symbol: H5Tget_class libhdf5 itself is loading this shared library and unable to resolve a symbol within itself, which is strange. Looking again at H5PL_OPEN_DLIB, it expands to dlopen(libname, RTLD_NOW). RTLD_NOW requires that all symbols used by the shared library be resolved at that point and produces the above error if they can’t. I don’t know enough about the dynamic linker to understand why that’s the case here, but changing it to RTLD_LAZY fixes the problem (RTLD_LAZY performs lazy binding). Bottom line: I suggest that plugins be loaded using RTLD_LAZY so that plugins that use libhdf5 functions don’t need to link with it. I’m not sure if this would solve the similar Java issues, or what the equivalent on Windows would be. Regards, Derick > On 18 May 2016, at 18:26, Derick Swanepoel <[email protected]> wrote: > > Good day, > > We’ve been developing a compression filter and have discovered that tools > such as h5dump and libraries such as h5py fail to load the filter, while our > own C++ tools that read/write datasets using the filter work fine. However, > explicitly linking the filter with libpthread allows h5dump to load it, and > additionally linking it with libhdf5 allows h5py to load it. > > Our C++ tools are already linked with these libraries which would explain why > they have no trouble loading it. > > I see that someone came across a similar issue before and it was recommended > that filters that use HDF5 calls should link with the library > (https://lists.hdfgroup.org/pipermail/hdf-forum_lists.hdfgroup.org/2015-December/009100.html). > I’m not sure I understand why this is necessary, since any code that is > capable of opening an HDF5 file would already link with libhdf5. > > If this is normal, perhaps it’s worth noting in the filter documentation, > especially since implementing a set_local callback would almost certainly > involve calling some HDF5 functions (we use it to determine type size, etc.) > > Regards, > Derick _______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org Twitter: https://twitter.com/hdf5
