As you know, the H5P{set,get}_fapl_mpiposix functions belonged to the HDF5
parallel library, and we do not support shared parallel HDF5 library. One
has to specifically enable “shared" at configure time to build it.
Just to be clear, parallel is supported, and shared is supported, but not
parallel and shared? Is the rationale for this explained somewhere?
For the sequential HDF5 library compatibility was not violated. Said this,
I would like to bring to your attention the following dilemma we face.
The HDF5 library can be built using many configurations; for example, one
can disable deprecated symbols like H5Dopen1, and build another version of
the sequential shared HDF5 library. The library in that configuration is
not compatible with the HDF5 library built from the same distribution.
I.e., if we follow the rules, we will need to maintain sonames for every
possible build configuration of HDF5. My examples above show three
non-compatible versions:
“default” - build with ./configure
“light” - built with ./configure —disable-depracted-symbols
“parallel” - built with ./configure —enable-parallel —enable-shared
Our current approach is to follow the soname rules only for the “default”
configuration. We will appreciate any suggestions on how to solve the
problem.
My instinct is that you should provide a consistent set of
externally-facing symbols for the entire HDF5 library (including shared and
parallel builds), and in situations where the function is not available,
calls to that function should raise an HDF5 not implemented error. Jed,
how does PETSc handle this?
I don't know how maintainers deal with "light" versions of their
libraries. If the symbols are deprecated but not removed from this version
of HDF5, then the soname version should probably be bumped to reflect
this. That said, I think it's more important that the default/parallel
public APIs to libhdf5.so are identical than that the "light" version be
properly versioned.
A
