[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Plea to fix the [ parallel | serial ] HDF5 problem

Hash: SHA256

On 12/06/2014 18:49, Gilles Filippini wrote:

Not so much, once the first bit is done the rest is really human
review.  From here, any new release should
be checked for changes using dpkg-gensymbols; additions are trivial,
deletions cause SONAME bumps;
modifications are more complex  but the procedure is documented in the
GNU ld manual and glibc examples.

They could be, but there is little advantage. One file is simpler to

I don't think so;  the hdf5 lib does, but higher up levels just use an
opaque handle
and don't see the internal MPI structures.

Point taken about the SONAME bump; yes, people will be rebuilding anyway.

I think whats not apparent is that this is still a work in progress; the
patch doesn't yet
do what I hope we can achieve.

I hope to enable use of multiple HDF5 flavours but transparently
without  causing multiple
unnecesssary packages. I think this can be done, but I'm not there yet;
I'll explain.

But first, I think that upstream will solve the design bug, just not in
time for jessie. I hope that
for zurg we will have a single HDF5 library, which can provide all the
functionality simultaneously.
In the meantime I would like Debian to provide all the functionality
without an explosion in
packages. As it stands (with this patch) we would still need to make
separate serial and MPI versions
of all packages that use HDF5 to provide functionality.

I've been experimenting with using filter libraries to solve this.

As noted, any package that explicitly uses serial functionality (eg.
threads) or MPI will need to explicitly
require the appropriate libarary, and so link (eventually?) against a
library with soname libhdf5_serial.so.
However packages that don't should be able to link simply with -lhdf5
and end up linking against a library
with soname libhdf5.so, which may be switched with either using
I haven't got a full solution yet, but the bits I have look like this:

Add a (private) lib libhdf5_bounce_serial.so, with libhdf5.so a symlink
to it. libhdf5_bounce_serial.so
is linkegd against libhdf5_serial.so:
$ ld -shared -Wl,--version-script serial.map -Wl,--soname, libhdf5.so -f
libhdf5_serial.so dummy.so
where dummy.so has some unused code.
Now clients can link against libhdf5.so and get the right functionality.
libhdf5_bounce_serial.so ships in libhdf5_serial and ditto for
libhdf5_bounce_mpi.so in libdf5_mpi ;
the libhdf5 symlink gets moved using alternatives.

This sort of works, but linking this way strips the use of symbols ;
clients linked against libhdf5_bounce.so
don't get versioned symbols; adding versioned symbols breaks the filter
functionality (-f). I'm still working
on this bit.

This adds a lot of complexity to the hdf5 packages, but it avoids an
explosion of packages elsewhere
in Debian and can be backed out when the HDF5 serial vs mpi bug is solved.

best regards

- -- 
Alastair McKinstry, <alastair@sceal.ie>, <mckinstry@debian.org>,
A decent provision for the poor is the true test of civilization.
~Samuel Johnson, Boswell: Life of Johnson
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


Reply to: