Hi Ghislain, Ghislain Vaillant a écrit le 01/11/2016 à 17:13 : > Thanks for dealing with the HDF 1.10 compatibility for ismrmrd whilst I > was away. I did not have the opportunity to look at your patch before > your submission today. That's unfortunate, as there are a couple of > problems with it. > > First, you changed the API by modifying the ISMRMRD_Dataset structure, > which upstream might not be so happy about.
Sorry about that. See below for the axplanation. > Then, the introduction of hid_t and resulting dependency on the hdf5 > header was not reflected on the install dependencies of the > libismrmrd-dev package, which broke the packaging CI testing. A trial > build on debomatic would have probably caught it. I've experienced repeated random failures using debomatic in the past. > Could you give me more insight of the compatibility problem with HDF5 1.10? The most important change in the HDF5 1.10 release is that the hid_t type was changed from 'int' to 'long long' [1]. Assuming that hid_t is int isn't true anymore. Thus the change to the ISMRMRD_Dataset structure, because the fileid field is actually used as an hid_t. See for example the ismrmrd_open_dataset() function in libsrc/dataset.c: int ismrmrd_open_dataset(ISMRMRD_Dataset *dset, const bool create_if_needed) { /* TODO add a mode for clobbering the dataset if it exists. */ hid_t fileid; ... fileid = H5Fopen(dset->filename, H5F_ACC_RDWR, H5P_DEFAULT); if (fileid > 0) { dset->fileid = fileid; } ... I can see two solutions: 1- make libismrmrd-dev depend on libhdf5-dev 2- set fileid as type long long to avoid including hdf5.h What do you think? [1] <https://support.hdfgroup.org/ftp/HDF5/releases/hdf5-1.10/hdf5-1.10.0-patch1/src/hdf5-1.10.0-patch1-RELEASE.txt> Thanks, _g.
signature.asc
Description: OpenPGP digital signature