<html>#2238: update HDF5 in ExternalLibraries to 1.10.X
<table style='border-spacing: 1ex 0pt; '>
<tr><td style='text-align:right'> Reporter:</td><td>Roland Haas</td></tr>
<tr><td style='text-align:right'> Status:</td><td>new</td></tr>
<tr><td style='text-align:right'>Milestone:</td><td></td></tr>
<tr><td style='text-align:right'> Version:</td><td></td></tr>
<tr><td style='text-align:right'> Type:</td><td>enhancement</td></tr>
<tr><td style='text-align:right'> Priority:</td><td>trivial</td></tr>
<tr><td style='text-align:right'>Component:</td><td></td></tr>
</table>
<p>HDF5 changed both the ABI and the possible on-disk file format in the 1.10 release. The former shows up in that <code>hid_t</code> and the other HDF5 handle types are no longer <code>int</code> but <code>long int</code>. The latter shows up only if the file format requested when creating the file is LATEST rather than EARLIEST (or 1.8 if such a define exists I guess).</p>
<p>Cactus will never write these new files itself (since we typically request the earliest possible file version that supports the features used, which is a very old one). However since HDF5 files are not backwards compatible it can happen that Cactus cannot read files written by other code.</p>
<p>It would be good to update the included HDF5 version to 1.10 to avoid this. All current Einstein Toolkit code is HDF5 1.10 safe, typical error messages for code that makes the assumption that <code>hid_t == int</code> are failures reporting a handle of <code>-1</code> at runtime (and potentially warnings about casting <code>hid_t</code> to a smaller type at compile time).</p>
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/2238/update-hdf5-in-externallibraries-to-110x'>https://bitbucket.org/einsteintoolkit/tickets/issues/2238/update-hdf5-in-externallibraries-to-110x</a></p>
</html>