Re: Plea to fix the [ parallel | serial ] HDF5 problem
-----BEGIN PGP SIGNED MESSAGE-----
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
maintain.
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
alternatives.
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
- --
Alastair McKinstry, <alastair@sceal.ie>, <mckinstry@debian.org>,
https://diaspora.sceal.ie/u/amckinstry
A decent provision for the poor is the true test of civilization.
~Samuel Johnson, Boswell: Life of Johnson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTnqhYAAoJEN9LdrZRJ3Qs02AP/jSIC5LS04mT1spkIMSy0aey
HWFvmCbRN7qioQgaii835nKu1qJiewMGvSPJigbhmGqxSn5RB4UirYEOsxgtDN7P
uMFx7efS/ihYUaKpoQRDtNr2GxTlKj7hZLaFfmIW++WBRQDEW+gMQOe8wnHgEeHA
3IF5r5GBjO54eLlfRQulMfrwwXZzCm6aFq4YUnDtIBmij+QIdiS7EbT7zOPFpMQ4
uJelVZ9tUgr6j2o2qMjWOpZBS1pEXHPrcvoyBWKU5uIvW2ncghpP4e1sRu/w3ELr
f/rMstZydW3gvFAls8Slx0OJ7B8Giq+NGoLUkPF5eEoR9Q/dq6V7uFbcejb/57wI
SIzB1j+pl/bDdAmUymR3HKkvnyOyQ6LSuCvZ0+Mku+5L8nTcMEBzkxRvH1QZEGZc
8a+5FVnD4f+tqq5tngky2YdRKaMSSQ4h/NJ5HzKbESLwbMy61F9VIzL86S36BS5J
6MGhNy/X/yGnGbm6TY18ktp3YWPFs//N32uKrOtrMBrJPfMgun+2Tg2ab5YJ/SIq
IU5CeAI59VErJIsbwMozVxizlq1+4JHrZgeq5CrOnFg0tOIEtBM4G3SbTOFbiNzP
ZHkUT90jenIVTtlI20Ok1hnca3IDR0LyuSHiPetK808dlqAlaPHUxkduSMiKC3BF
9fq/AcSJKACFDMDQxd6Z
=LmEQ
-----END PGP SIGNATURE-----
Reply to: