jhendersonHDF

Hi all, I just tested @fortnern's test program here, as well as some internal test programs, with the `v4.1.x-202207280243-88bb627` snapshot. It runs successfully for me on a Slackware Linux system,...

@opoplawski Would it be possible to try the same builds using at least MPICH 4.0.3 to see if there were any bugs fixed that may have caused these issues?

Hi @opoplawski, hopefully https://github.com/HDFGroup/hdf5/commit/af56339d3bb0ba0076c10f929472f766c9a9a5af should fix this, at least for the t_filters_parallel test.. It should be merged back to the hdf5_1_14 branch soon.

> I understand the motivation and generally like this change. But, I'm concerned that the #ifdef'd code will languish and then rot (i.e. not work correctly) without a regular (if...

Marking this PR as a draft for now, since it looks like it's exposing an issue in the H5T code for `long double -> float` and `long double -> double`...

> [CVE-2020-10812](https://github.com/advisories/GHSA-g838-rwc8-xv7q) unveils a more fundamental design flaw in H5F__dest(): this function returns FAIL if one of multiple operations fail (in this case H5AC_prep_for_file_close()) while it still proceeds to prepare...

Hi @bhawkins and @mkitti, if you happen to get the chance it would be appreciated if you could look over the RFC for 16-bit float (and complex number) support at...

At first glance: `/libtoolize --copy --force` seems to be the issue. `libtoolize` certainly isn't going to be found there unless you have a strange system! Looks like autogen.sh had a...

> I recommend more defense programming w.r.t. the following Agreed on this. It looks like we only use `libtool` to find the directory for `libtoolize`, so it may be fine...

@mathstuf Apologies, I made a bunch of changes recently to cleanup some of the remaining warnings in the develop branch and it seems it caused conflicts among your PRs; it...