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

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

Alastair McKinstry a écrit , Le 12/06/2014 07:54:
> On 12/06/2014 00:43, Gilles Filippini wrote:
>> Alastair McKinstry a écrit , Le 11/06/2014 12:15:
>>> I've pushed some work on this to a dev-alternatives branch on alioth.
>> Thanks a lot for this work.
>> How did you produce the detailed map files? What is the recipe to use
>> when updating to a new upstream release?
> The symbols change information came via dpkg-gensymbols. In practice the
> map file needs
> to be done by hand as you need to check what symbols changed and how (to
> cope with modifications
> rather than just additions).
> As this is the first versioning map file, the symbol names have no
> significance other than to
> document the version in which they were added, but it is important to
> enumerate each symbol
> and eliminate as many local symbols as possible.

This actually is a huge task. Some helper scripts might be desirable here.

BTW, shouldn't these map files be split into parts so that each one
matches one target library: libhdf5, libhdf5_fortran, ...?

> For linking multiple hdf libs, the symbol names need to be different
> between variants, hence
> HDF5_SERIAL_1.8.11 vs HDF_MPI_1.8.11
> As far as I can tell, the MPI variants are equivalent.
>>> This is still a work in progress but I've got co-installable serial &
>>> parallel netcdf building from this;
>> As I said before I really don't see any use for setting an alternative
>> against all flavors of the library. What could be the use case for that?
> My aim is that any existing setup will continue to work; ie. if you have
> mpich2 and hdf5-mipch2 dev libs
> installed on a wheezy system with local binaries built, then this should
> still work when upgraded to jessie.
> Also, any upgrades should minimize necessary changes. If you build a
> binary locally with openmpi + hdf5 openmpi,
> then change to mpich, it should continue to work , as the binary will
> have been built against the  hdf5_mpi interface
> rather than an mpi-implementation specific version.
I'm relly not sure about this last part. Won't the resulting executables
have a dependancy on the MPI flavor they were linked with in the first

> Do you think we should not do this, or do this differently?

My take on this is that - because of the soname bump - downstream users
will *have to* rebuild their software depending on libhdf5, anyway. Then
I'd prefer a big fat warning telling them to add proper -I and -L flags
than carrying misleading and mutually exclusive default configurations
via alternatives. The whole purpose of this work is to get rid of this
kind of conflicting settings after all.

>>> For the incongruity, I'd already implemented the rename when you replied
>>> and found it easier
>>> to simply add a symlink for compatability. I can back it out if peeople
>>> disagree.
>> I still disagree about changing an upstream library name just for a
>> cosmetic matter.
> Ok, i'll back it out.


I'm going to have a relly busy w-e. I'll start to merge your changes
into my experimental branch by monday.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: