summaryrefslogtreecommitdiffstats
path: root/release_docs/RELEASE.txt
diff options
context:
space:
mode:
authorLarry Knox <lrknox@hdfgroup.org>2022-05-19 23:35:50 (GMT)
committerGitHub <noreply@github.com>2022-05-19 23:35:50 (GMT)
commitb2794b474acaf9050b03239502056bdd34975db8 (patch)
tree98d069093e2ef5651be5eb199041791ebeeedc89 /release_docs/RELEASE.txt
parenta6f7dccbd6c6b10ac0051a54bf7e35dedf685861 (diff)
downloadhdf5-b2794b474acaf9050b03239502056bdd34975db8.zip
hdf5-b2794b474acaf9050b03239502056bdd34975db8.tar.gz
hdf5-b2794b474acaf9050b03239502056bdd34975db8.tar.bz2
Update version to 1.10.10-1 (#1783)
Update so numbers to match 1.10.9 release. Clear 1.10.9 entries from RELEASE.txt.
Diffstat (limited to 'release_docs/RELEASE.txt')
-rw-r--r--release_docs/RELEASE.txt443
1 files changed, 112 insertions, 331 deletions
diff --git a/release_docs/RELEASE.txt b/release_docs/RELEASE.txt
index dfae866..175e86f 100644
--- a/release_docs/RELEASE.txt
+++ b/release_docs/RELEASE.txt
@@ -1,4 +1,4 @@
-HDF5 version 1.10.9-1 currently under development
+HDF5 version 1.10.10-1 currently under development
================================================================================
@@ -49,90 +49,13 @@ New Features
Configuration:
-------------
- - Added new option to the h5cc scripts produced by CMake.
-
- Add -showconfig option to h5cc scripts to cat the
- libhdf5-settings to the standard output.
-
- (ADB - 2022/03/11)
-
- - HDF5 memory allocation sanity checking is now off by default for
- Autotools debug builds
-
- HDF5 can be configured to perform sanity checking on internal memory
- allocations by adding heap canaries to these allocations. However,
- enabling this option can cause issues with external filter plugins
- when working with (reallocating/freeing/allocating and passing back)
- buffers.
-
- Previously, this option was off by default for all CMake build types,
- but only off by default for non-debug Autotools builds. Since debug
- is the default build mode for HDF5 when built from source with
- Autotools, this can result in surprising segfaults that don't occur
- when an application is built against a release version of HDF5.
- Therefore, this option is now off by default for all build types
- across both CMake and Autotools.
-
- (JTH - 2022/03/01)
-
- - Refactored the utils folder.
-
- Added subfolder test and moved the 'swmr_check_compat_vfd.c file'
- from test into utils/test. Deleted the duplicate swmr_check_compat_vfd.c
- file in hl/tools/h5watch folder. Also fixed vfd check options.
-
- (ADB - 2021/10/18)
-
- - Changed autotools and CMake configurations to derive both
- compilation warnings-as-errors and warnings-only-warn configurations
- from the same files, 'config/*/*error*'. Removed redundant files
- 'config/*/*noerror*'.
-
- (DCY - 2021/09/29)
+ -
Library:
--------
- - Several improvements to parallel compression feature, including:
-
- * Improved support for collective I/O (for both writes and reads)
-
- * Significant reduction of memory usage for the feature as a whole
-
- * Reduction of copying of application data buffers passed to H5Dwrite
-
- * Addition of support for incremental file space allocation for filtered
- datasets created in parallel. Incremental file space allocation is the
- default for these types of datasets (early file space allocation is
- also still supported), while early file space allocation is still the
- default (and only supported allocation time) for unfiltered datasets
- created in parallel. Incremental file space allocation should help with
- parallel HDF5 applications that wish to use fill values on filtered
- datasets, but would typically avoid doing so since dataset creation in
- parallel would often take an excessive amount of time. Since these
- datasets previously used early file space allocation, HDF5 would
- allocate space for and write fill values to every chunk in the dataset
- at creation time, leading to noticeable overhead. Instead, with
- incremental file space allocation, allocation of file space for chunks
- and writing of fill values to those chunks will be delayed until each
- individual chunk is initially written to.
-
- * Addition of support for HDF5's "don't filter partial edge chunks" flag
- (https://portal.hdfgroup.org/display/HDF5/H5P_SET_CHUNK_OPTS)
-
- * Addition of proper support for HDF5 fill values with the feature
-
- * Addition of 'H5_HAVE_PARALLEL_FILTERED_WRITES' macro to H5pubconf.h
- so HDF5 applications can determine at compile-time whether the feature
- is available
-
- * Addition of simple examples (ph5_filtered_writes.c and
- ph5_filtered_writes_no_sel.c) under examples directory to demonstrate
- usage of the feature
-
- * Improved coverage of regression testing for the feature
+ -
- (JTH - 2022/2/23)
Fortran Library:
----------------
@@ -151,13 +74,7 @@ New Features
Tools:
------
- - h5repack added an optional verbose value for reporting R/W timing.
-
- In addition to adding timing capture around the read/write calls in
- h5repack, added help text to indicate how to show timing for read/write;
- -v N, --verbose=N Verbose mode, print object information.
- N - is an integer greater than 1, 2 displays read/write timing
- (ADB - 2022/04/01)
+ -
High-Level APIs:
@@ -185,83 +102,12 @@ Support for new platforms, languages and compilers
-
-Bug Fixes since HDF5-1.10.7 release
+Bug Fixes since HDF5-1.10.9 release
===================================
Library
-------
- - Fixed a metadata cache bug when resizing a pinned/protected cache entry
-
- When resizing a pinned/protected cache entry, the metadata
- cache code previously would wait until after resizing the
- entry to attempt to log the newly-dirtied entry. This would
- cause H5C_resize_entry to mark the entry as dirty and make
- H5AC_resize_entry think that it doesn't need to add the
- newly-dirtied entry to the dirty entries skiplist.
-
- Thus, a subsequent H5AC__log_moved_entry would think it
- needs to allocate a new entry for insertion into the dirty
- entry skip list, since the entry doesn't exist on that list.
- This causes an assertion failure, as the code to allocate a
- new entry assumes that the entry is not dirty.
-
- (JRM - 2022/02/28)
-
- - Issue #1436 identified a problem with the H5_VERS_RELEASE check in the
- H5check_version function.
-
- Investigating the original fix, #812, we discovered some inconsistencies
- with a new block added to check H5_VERS_RELEASE for incompatibilities.
- This new block was not using the new warning text dealing with the
- H5_VERS_RELEASE check and would cause the warning to be duplicated.
-
- By removing the H5_VERS_RELEASE argument in the first check for
- H5_VERS_MAJOR and H5_VERS_MINOR, the second check would only check
- the H5_VERS_RELEASE for incompatible release versions. This adheres
- to the statement that except for the develop branch, all release versions
- in a major.minor maintenance branch should be compatible. The prerequisite
- is that an application will not use any APIs not present in all release versions.
-
- (ADB - 2022/03/11, #1438)
-
- - Unified handling of collective metadata reads to correctly fix old bugs
-
- Due to MPI-related issues occurring in HDF5 from mismanagement of the
- status of collective metadata reads, they were forced to be disabled
- during chunked dataset raw data I/O in the HDF5 1.10.5 release. This
- wouldn't generally have affected application performance because HDF5
- already disables collective metadata reads during chunk lookup, since
- it is generally unlikely that the same chunks will be read by all MPI
- ranks in the I/O operation. However, this was only a partial solution
- that wasn't granular enough.
-
- This change now unifies the handling of the file-global flag and the
- API context-level flag for collective metadata reads in order to
- simplify querying of the true status of collective metadata reads. Thus,
- collective metadata reads are once again enabled for chunked dataset
- raw data I/O, but manually controlled at places where some processing
- occurs on MPI rank 0 only and would cause issues when collective
- metadata reads are enabled.
-
- (JTH - 2021/11/16, HDFFV-10501/HDFFV-10562)
-
- - Fixed several potential MPI deadlocks in library failure conditions
-
- In the parallel library, there were several places where MPI rank 0
- could end up skipping past collective MPI operations when some failure
- occurs in rank 0-specific processing. This would lead to deadlocks
- where rank 0 completes an operation while other ranks wait in the
- collective operation. These places have been rewritten to have rank 0
- push an error and try to cleanup after the failure, then continue to
- participate in the collective operation to the best of its ability.
-
- (JTH - 2021/11/09)
-
- - Fixed an issue with collective metadata reads being permanently disabled
- after a dataset chunk lookup operation. This would usually cause a
- mismatched MPI_Bcast and MPI_ERR_TRUNCATE issue in the library for
- simple cases of H5Dcreate() -> H5Dwrite() -> H5Dcreate().
-
- (JTH - 2021/11/08, HDFFV-11090)
+ -
+
Java Library
------------
@@ -270,16 +116,7 @@ Bug Fixes since HDF5-1.10.7 release
Configuration
-------------
- - Reworked corrected path searched by CMake find_package command
-
- The install path for cmake find_package files had been changed to use
- "share/cmake"
- for all platforms. However setting the HDF5_ROOT variable failed to locate
- the configuration files. The build variable HDF5_INSTALL_CMAKE_DIR is now
- set to the <INSTALL_DIR>/cmake folder. The location of the configuration
- files can still be specified by the "HDF5_DIR" variable.
-
- (ADB - 2022/03/11)
+ -
Tools
@@ -294,11 +131,7 @@ Bug Fixes since HDF5-1.10.7 release
High-Level Library
------------------
- - Fixed HL_test_packet, test for packet table vlen of vlen.
-
- Incorrect length assignment.
-
- (ADB - 2021/10/14)
+ -
Fortran High-Level APIs
@@ -326,170 +159,110 @@ Bug Fixes since HDF5-1.10.7 release
-
-Supported Platforms
+Platforms Tested
===================
- Linux 3.10.0-1127.10.1.el7 gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
- #1 SMP ppc64 GNU/Linux g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
- (echidna) GNU Fortran (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
-
- Linux 2.6.32-754.31.1.el6 IBM XL C/C++ V13.1
- #1 SMP ppc64 GNU/Linux IBM XL Fortran V15.1
- (ostrich)
-
- Linux 3.10.0-327.18.2.el7 GNU C (gcc), Fortran (gfortran), C++ (g++)
- #1 SMP x86_64 GNU/Linux compilers:
- (jelly/kituo/moohan) Version 4.8.5 20150623 (Red Hat 4.8.5-4)
- Version 4.9.3, Version 5.3.0, Version 6.3.0,
- Version 7.2.0, Version 8.3.0, Version 9.1.0
- Intel(R) C (icc), C++ (icpc), Fortran (icc)
- compilers:
- Version 17.0.0.098 Build 20160721
- MPICH 3.3 compiled with GCC 7.2.0
- OpenMPI 4.0.0 compiled with GCC 7.2.0
-
- SunOS 5.11 11.4.5.12.5.0 Sun C 5.15 SunOS_sparc 2017/05/30
- 32- and 64-bit Studio 12.6 Fortran 95 8.8 SunOS_sparc 2017/05/30
- (hedgehog) Sun C++ 5.15 SunOS_sparc 2017/05/30
-
- Windows 10 x64 Visual Studio 2015 w/ Intel Fortran 18 (cmake)
- Visual Studio 2017 w/ Intel Fortran 19 (cmake)
- Visual Studio 2019 w/ Intel Fortran 19 (cmake)
- Visual Studio 2019 w/ MSMPI 10.1 (cmake)
-
- macOS Mojave 10.14.6 Apple LLVM version 10.0.1 (clang-1001.0.46.4)
- 64-bit gfortran GNU Fortran (GCC) 6.3.0
- (swallow) Intel icc/icpc/ifort version 19.0.4.233 20190416
-
-Tested Configuration Features Summary
-=====================================
-
- In the tables below
- y = tested
- n = not tested in this release
- C = Cluster
- W = Workstation
- x = not working in this release
- dna = does not apply
- ( ) = footnote appears below second table
- <blank> = testing incomplete on this feature or platform
-
-Platform C F90/ F90 C++ zlib SZIP
- parallel F2003 parallel
-Solaris2.11 32-bit n y/y n y y y
-Solaris2.11 64-bit n y/n n y y y
-Windows 10 y y/y n y y y
-Windows 10 x64 y y/y n y y y
-Mac OS X El Capitan 10.11.6 64-bit n y/y n y y y
-Mac OS Sierra 10.12.6 64-bit n y/y n y y y
-Mac OS X High Sierra 10.13.6 64-bit n y/y n y y y
-Mac OS X Mojave 10.14.6 64-bit n y/y n y y y
-CentOS 7.2 Linux 2.6.32 x86_64 PGI n y/y n y y y
-CentOS 7.2 Linux 2.6.32 x86_64 GNU y y/y y y y y
-CentOS 7.2 Linux 2.6.32 x86_64 Intel n y/y n y y y
-Linux 2.6.32-573.18.1.el6.ppc64 n y/y n y y y
-
-
-Platform Shared Shared Shared Thread-
- C libs F90 libs C++ libs safe
-Solaris2.11 32-bit y y y y
-Solaris2.11 64-bit y y y y
-Windows 10 y y y y
-Windows 10 x64 y y y y
-Mac OS X El Capitan 10.11.6 64-bit y n y y
-Mac OS Sierra 10.12.6 64-bit y n y y
-Mac OS X High Sierra 10.13.6 64-bit y n y y
-Mac OS X Mojave 10.14.6 64-bit y n y y
-CentOS 7.2 Linux 2.6.32 x86_64 PGI y y y n
-CentOS 7.2 Linux 2.6.32 x86_64 GNU y y y y
-CentOS 7.2 Linux 2.6.32 x86_64 Intel y y y n
-Linux 2.6.32-573.18.1.el6.ppc64 y y y n
-
-Compiler versions for each platform are listed in the preceding
-"Supported Platforms" table.
-
-
-More Tested Platforms
-=====================
-The following platforms are not supported but have been tested for this release.
-
- Linux 2.6.32-573.22.1.el6 GNU C (gcc), Fortran (gfortran), C++ (g++)
- #1 SMP x86_64 GNU/Linux compilers:
- (platypus) Version 4.4.7 20120313
- Version 4.9.3, 5.3.0, 6.2.0
- PGI C, Fortran, C++ for 64-bit target on
- x86-64;
- Version 19.10-0
- MPICH 3.1.4 compiled with GCC 4.9.3
-
- Linux 2.6.32-754.31.1.el6 gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18)
- #1 SMP ppc64 GNU/Linux g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18)
- (ostrich) GNU Fortran (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18)
-
- Linux 3.10.0-327.18.2.el7 GNU C (gcc) and C++ (g++) compilers
- #1 SMP x86_64 GNU/Linux Version 4.8.5 20150623 (Red Hat 4.8.5-4)
- (jelly) with NAG Fortran Compiler Release 6.1(Tozai)
- GCC Version 7.1.0
- OpenMPI 2.1.6-GCC-7.2.0-2.29,
- 3.1.3-GCC-7.2.0-2.29
- Intel(R) C (icc) and C++ (icpc) compilers
- Version 17.0.0.098 Build 20160721
- with NAG Fortran Compiler Release 6.1(Tozai)
-
- Linux 3.10.0-327.10.1.el7 MPICH 3.1.4 compiled with GCC 4.9.3
- #1 SMP x86_64 GNU/Linux
- (moohan)
-
- Linux-3.10.0-1127.0.0.1chaos openmpi-4.0.0
- #1 SMP x86_64 GNU/Linux clang/3.9.0, 8.0.1
- (quartz) gcc/7.3.0, 8.1.0
- intel/16.0.4
-
- Linux-4.14.0-115.10.1.1 spectrum-mpi/rolling-release
- #1 SMP ppc64le GNU/Linux clang/coral-2018.08.08
- (lassen) gcc/7.3.1
- xl/2019.02.07
-
- Linux-4.12.14-150.52-default cray-mpich/7.7.10
- #1 SMP x86_64 GNU/Linux gcc/7.3.0, 8.2.0
- (cori) intel/19.0.3
-
- Linux-4.4.180-94.107-default cray-mpich/7.7.6
- # 1SMP x86_64 GNU/Linux gcc/7.2.0, 8.2.0
- (mutrino) intel/17.0.4, 18.0.2, 19.0.4
-
- Fedora33 5.10.10-200.fc33.x86_64
- #1 SMP x86_64 GNU/Linux GNU gcc (GCC) 10.2.1 20201125 (Red Hat 10.2.1-9)
- GNU Fortran (GCC) 10.2.1 20201125 (Red Hat 10.2.1-9)
- clang version 11.0.0 (Fedora 11.0.0-2.fc33)
+ Linux 5.13.14-200.fc34 GNU gcc (GCC) 11.2.1 2021078 (Red Hat 11.2.1-1)
+ #1 SMP x86_64 GNU/Linux GNU Fortran (GCC) 11.2.1 2021078 (Red Hat 11.2.1-1)
+ Fedora34 clang version 12.0.1 (Fedora 12.0.1-1.fc34)
(cmake and autotools)
- Ubuntu20.10 5.8.0-41-generic-x86_64
- #46-Ubuntu SMP x86_64 GNU/Linux GNU gcc (GCC) 10.2.0-13ubuntu1
- GNU Fortran (GCC) 10.2.0-13ubuntu1
+ Linux 5.11.0-34-generic GNU gcc (GCC) 9.3.0-17ubuntu1
+ #36-Ubuntu SMP x86_64 GNU/Linux GNU Fortran (GCC) 9.3.0-17ubuntu1
+ Ubuntu 20.04 Ubuntu clang version 10.0.0-4
(cmake and autotools)
- SUSE15sp2 5.3.18-22-default
- #1 SMP x86_64 GNU/Linux GNU gcc (SUSE Linux) 7.5.0
- GNU Fortran (SUSE Linux) 7.5.0
- clang version 7.0.1 (tags/RELEASE_701/final 349238)
+ Linux 5.8.0-63-generic GNU gcc (GCC) 10.3.0-1ubuntu1
+ #71-Ubuntu SMP x86_64 GNU/Linux GNU Fortran (GCC) 10.3.0-1ubuntu1
+ Ubuntu20.10 Ubuntu clang version 11.0.0-2
(cmake and autotools)
- Mac OS X El Capitan 10.11.6 Apple clang version 7.3.0 from Xcode 7.3
- 64-bit gfortran GNU Fortran (GCC) 5.2.0
- (osx1011test) Intel icc/icpc/ifort version 16.0.2
-
- macOS Sierra 10.12.6 Apple LLVM version 9.0.0 (clang-900.39.2)
- 64-bit gfortran GNU Fortran (GCC) 7.4.0
- (kite) Intel icc/icpc/ifort version 17.0.2
-
- macOS High Sierra 10.13.6 Apple LLVM version 10.0.0 (clang-1000.10.44.4)
- 64-bit gfortran GNU Fortran (GCC) 6.3.0
- (bear) Intel icc/icpc/ifort version 19.0.4.233 20190416
+ Linux 5.3.18-22-default GNU gcc (SUSE Linux) 7.5.0
+ #1 SMP x86_64 GNU/Linux GNU Fortran (SUSE Linux) 7.5.0
+ SUSE15sp2 clang version 7.0.1 (tags/RELEASE_701/final 349238)
+ (cmake and autotools)
- SunOS 5.11 11.3 Sun C 5.15 SunOS_sparc
- 32- and 64-bit Sun Fortran 95 8.8 SunOS_sparc
- (emu)
+ Linux-4.14.0-115.21.2 spectrum-mpi/rolling-release
+ #1 SMP ppc64le GNU/Linux clang 8.0.1, 11.0.1
+ (lassen) GCC 7.3.1
+ XL 16.1.1.2
+ (cmake)
+
+ Linux-4.12.14-150.75-default cray-mpich/7.7.10
+ #1 SMP x86_64 GNU/Linux GCC 7.3.0, 8.2.0
+ (cori) Intel (R) Version 19.0.3.199
+ (cmake)
+
+ Linux-4.12.14-197.86-default cray-mpich/7.7.6
+ # 1SMP x86_64 GNU/Linux GCC 7.3.0, 9.3.0, 10.2.0
+ (mutrino) Intel (R) Version 17.0.4, 18.0.5, 19.1.3
+ (cmake)
+
+ Linux 3.10.0-1160.36.2.el7.ppc64 gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
+ #1 SMP ppc64be GNU/Linux g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
+ Power8 (echidna) GNU Fortran (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
+
+ Linux 3.10.0-1160.24.1.el7 GNU C (gcc), Fortran (gfortran), C++ (g++)
+ #1 SMP x86_64 GNU/Linux compilers:
+ Centos7 Version 4.8.5 20150623 (Red Hat 4.8.5-4)
+ (jelly/kituo/moohan) Version 4.9.3, Version 5.3.0, Version 6.3.0,
+ Version 7.2.0, Version 8.3.0, Version 9.1.0
+ Intel(R) C (icc), C++ (icpc), Fortran (icc)
+ compilers:
+ Version 17.0.0.098 Build 20160721
+ GNU C (gcc) and C++ (g++) 4.8.5 compilers
+ with NAG Fortran Compiler Release 6.1(Tozai)
+ Intel(R) C (icc) and C++ (icpc) 17.0.0.098 compilers
+ with NAG Fortran Compiler Release 6.1(Tozai)
+ MPICH 3.1.4 compiled with GCC 4.9.3
+ MPICH 3.3 compiled with GCC 7.2.0
+ OpenMPI 2.1.6 compiled with icc 18.0.1
+ OpenMPI 3.1.3 and 4.0.0 compiled with GCC 7.2.0
+ PGI C, Fortran, C++ for 64-bit target on
+ x86_64;
+ Version 19.10-0
+
+ Linux-3.10.0-1127.0.0.1chaos openmpi-4.0.0
+ #1 SMP x86_64 GNU/Linux clang 6.0.0, 11.0.1
+ (quartz) GCC 7.3.0, 8.1.0
+ Intel 16.0.4, 18.0.2, 19.0.4
+
+ macOS Apple M1 11.6 Apple clang version 12.0.5 (clang-1205.0.22.11)
+ Darwin 20.6.0 arm64 gfortran GNU Fortran (Homebrew GCC 11.2.0) 11.1.0
+ (macmini-m1) Intel icc/icpc/ifort version 2021.3.0 20210609
+
+ macOS Big Sur 11.3.1 Apple clang version 12.0.5 (clang-1205.0.22.9)
+ Darwin 20.4.0 x86_64 gfortran GNU Fortran (Homebrew GCC 10.2.0_3) 10.2.0
+ (bigsur-1) Intel icc/icpc/ifort version 2021.2.0 20210228
+
+ macOS High Sierra 10.13.6 Apple LLVM version 10.0.0 (clang-1000.10.44.4)
+ 64-bit gfortran GNU Fortran (GCC) 6.3.0
+ (bear) Intel icc/icpc/ifort version 19.0.4.233 20190416
+
+ macOS Sierra 10.12.6 Apple LLVM version 9.0.0 (clang-900.39.2)
+ 64-bit gfortran GNU Fortran (GCC) 7.4.0
+ (kite) Intel icc/icpc/ifort version 17.0.2
+
+ Mac OS X El Capitan 10.11.6 Apple clang version 7.3.0 from Xcode 7.3
+ 64-bit gfortran GNU Fortran (GCC) 5.2.0
+ (osx1011test) Intel icc/icpc/ifort version 16.0.2
+
+ Linux 2.6.32-573.22.1.el6 GNU C (gcc), Fortran (gfortran), C++ (g++)
+ #1 SMP x86_64 GNU/Linux compilers:
+ Centos6 Version 4.4.7 20120313
+ (platypus) Version 4.9.3, 5.3.0, 6.2.0
+ MPICH 3.1.4 compiled with GCC 4.9.3
+ PGI C, Fortran, C++ for 64-bit target on
+ x86_64;
+ Version 19.10-0
+
+ Windows 10 x64 Visual Studio 2015 w/ Intel C/C++/Fortran 18 (cmake)
+ Visual Studio 2017 w/ Intel C/C++/Fortran 19 (cmake)
+ Visual Studio 2019 w/ clang 12.0.0
+ with MSVC-like command-line (C/C++ only - cmake)
+ Visual Studio 2019
+ w/ Intel C/C++/Fortran oneAPI 2021 (cmake)
+ Visual Studio 2019 w/ MSMPI 10.1 (C only - cmake)
Known Problems
@@ -557,3 +330,11 @@ The share folder will have the most differences because CMake builds include
a number of CMake specific files for support of CMake's find_package and support
for the HDF5 Examples CMake project.
+The issues with the gif tool are:
+ HDFFV-10592 CVE-2018-17433
+ HDFFV-10593 CVE-2018-17436
+ HDFFV-11048 CVE-2020-10809
+These CVE issues have not yet been addressed and can be avoided by not building
+the gif tool. Disable building the High-Level tools with these options:
+ autotools: --disable-hltools
+ cmake: HDF5_BUILD_HL_TOOLS=OFF