-
-
Notifications
You must be signed in to change notification settings - Fork 7
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add files for Release Specific Information page
This is just to get the files in place. The contents are not formatted yet, hence, very untidy.
- Loading branch information
Showing
13 changed files
with
6,286 additions
and
0 deletions.
There are no files selected for viewing
78 changes: 78 additions & 0 deletions
78
documentation/hdf5-docs/release_specifics/Migrating+from+HDF5+1.10+to+HDF5+1.14.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,78 @@ | ||
--- | ||
title: Migrating from HDF5 1.10 to HDF5 1.12 | ||
redirect_from: | ||
- /display/HDF5/Migrating+from+HDF5+1.10+to+HDF5+1.12.html | ||
--- | ||
|
||
# Migrating from HDF5 1.10 to HDF5 1.12 | ||
|
||
Also see the video presentation: Moving Applications from 1.10 to 1.12 | ||
|
||
There were many existing functions that were modified in 1.12. Applications created with 1.10 or earlier that use these functions will encounter errors when compiled with 1.12. This page describes how to compile 1.10 and earlier applications with 1.12 without modifying an application, and provides details on the functions that changed for users who wish to update their applications: | ||
|
||
Compiling 1.10 and earlier applications with 1.12 | ||
Functions that changed | ||
For further information, see: | ||
|
||
New Features in 1.12 | ||
Software Changes from release to release | ||
API Compatibility Macros in HDF5 | ||
Compiling 1.10 and earlier applications with 1.12 | ||
Applications that were created with earlier HDF5 releases may not compile with 1.12 by default. The API Compatibility Macros in HDF5 allow users to work around this issue. Users can specify a compatibility macro mapping for the version of HDF5 that an application was built with. For example, a 1.10 application can be built with 1.12 using either an application or library mapping as follows: | ||
|
||
To compile an application built with a version of HDF5 that includes deprecated symbols (the default), make sure to pass -DH5_USE_110_API to the compiler. For example: | ||
|
||
Autotools: h5cc -DH5_USE_110_API (C) | ||
|
||
CMake: cmake -DCMAKE_C_FLAGS="-DH5_USE_110_API" (and likewise for other CMAKE_<LANG>_FLAGS) | ||
|
||
To build an HDF5 library with the 1.10 APIs specify --with-default-api-version=v110 (Autotools) or -DDEFAULT_API_VERSION:STRING=v110 (CMake). | ||
|
||
Autotools: | ||
./configure --with-default-api-version=v110 | ||
|
||
CMake: | ||
If using the source code packaged with CMake configuration files (CMake-hdf5-1.12.0*), edit HDF5options.cmake, and add this line: | ||
|
||
set(ADD_BUILD_OPTIONS "${ADD_BUILD_OPTIONS} -DDEFAULT_API_VERSION:STRING=v110") | ||
|
||
View the libhdf5.settings file to verify that the library was built with the 1.10 APIs: | ||
|
||
Default API mapping: v110 (under Features:) | ||
|
||
However, users will not be able to take advantage of some of the new features in 1.12 if using these compatibility mappings. | ||
|
||
Functions that changed | ||
Functions were modified in HDF5 version 1.12 to support a token type used in the Virtual Object Layer (VOL) and to enable 64-bit selection encodings. These changes are described below. | ||
|
||
The updated versions of the functions have a number (for eg '2' or '3') at the end of the original function name. The original versions of these functions were retained and renamed to have an earlier number (for eg '1') at the end of the original function name. A macro was created with the name of the original function. Please read API Compatibility Macros in HDF5 for more details on how the function names changed in version 1.12. | ||
|
||
Token Type | ||
In HDF5 1.12, a token type, H5O_token_t, replaced the address type, haddr_t, for representing locations in an HDF5 file. This change better supports the Virtual Object Layer (VOL), as the concept of an "address" does not make sense for many connectors. A token type is a more generic type that can function as both a connector and address location. | ||
|
||
This change affected the following functions: | ||
|
||
|
||
|
||
|
||
|
||
H5L_GET_INFO H5L_GET_INFO1 H5L_GET_INFO2 | ||
H5L_GET_INFO_BY_IDX H5L_GET_INFO_BY_IDX1 H5L_GET_INFO_BY_IDX2 | ||
H5L_ITERATE H5L_ITERATE1 H5L_ITERATE2 | ||
H5L_ITERATE_BY_NAME H5L_ITERATE_BY_NAME1 H5L_ITERATE_BY_NAME2 | ||
H5L_VISIT H5L_VISIT1 H5L_VISIT2 | ||
H5L_VISIT_BY_NAME H5L_VISIT_BY_NAME1 H5L_VISIT_BY_NAME2 | ||
H5O_GET_INFO H5O_GET_INFO1 H5O_GET_INFO3 | ||
H5O_GET_INFO_BY_IDX H5O_GET_INFO_BY_IDX1 H5O_GET_INFO_BY_IDX3 | ||
H5O_GET_INFO_BY_NAME H5O_GET_INFO_BY_NAME1 H5O_GET_INFO_BY_NAME3 | ||
H5O_VISIT H5O_VISIT1 H5O_VISIT3 | ||
H5O_VISIT_BY_NAME | ||
H5O_VISIT_BY_NAME1 | ||
|
||
H5O_VISIT_BY_NAME3 | ||
Encoding Properties | ||
These functions were introduced in HDF5 version 1.12 as part of the H5Sencode format change to enable 64-bit selection encodings and a dataspace selection that is tied to a file. See the H5Sencode / H5Sdecode format change RFC for details. | ||
|
||
|
||
H5P_ENCODE H5P_ENCODE1 H5P_ENCODE2 | ||
H5S_ENCODE H5S_ENCODE1 H5S_ENCODE2 |
38 changes: 38 additions & 0 deletions
38
documentation/hdf5-docs/release_specifics/Migrating+from+HDF5+1.12+to+HDF5+1.14.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,38 @@ | ||
--- | ||
title: Migrating from HDF5 1.12 to HDF5 1.14 | ||
redirect_from: | ||
- /display/HDF5/Migrating+from+HDF5+1.12+to+HDF5+1.14.html | ||
--- | ||
|
||
# Migrating from HDF5 1.12 to HDF5 1.14 | ||
|
||
## API Changes | ||
There are new API calls that require API Compatibility Macros in HDF5 1.14.0. There are, however, two API calls which have had their signature change. | ||
|
||
### `H5Iregister_type()` / `H5I_free_t` | ||
The signature of `H5Iregister_type()` did not change, but the `H5I_free_t` callback it accepts did have its signature change to add an asynchronous request parameter. There is no API compatibility macro to paper over this change. The request parameter can be ignored in the callback if you are not concerned with asynchronous operations and future IDs. A description of how the request parameter should be used will be found in the (soon to be released) HDF5 Asynchronous Programming Guide. | ||
|
||
 **Old:** | ||
|
||
 `typedef herr_t (*H5I_free_t)(void *obj);` | ||
|
||
 **New:** | ||
|
||
 `typedef herr_t (*H5I_free_t)(void *obj, void **request);` | ||
|
||
### `H5VLquery_optional()` | ||
The way optional operations are handled in the virtual object layer (VOL) changed significantly in HDF5 1.14.0. To better support this, the `H5VLquery_optional()` API call now takes an output flags parameter instead of a Boolean. Since the entire 1.12 VOL API has been deprecated, no API compatibility macro exists for this API call. | ||
|
||
 **Old:** | ||
|
||
 `herr_t H5VLquery_optional(hid_t obj_id, H5VL_subclass_t subcls, int opt_type, hbool_t *supported);` | ||
|
||
 **New:** | ||
|
||
 `herr_t H5VLquery_optional(hid_t obj_id, H5VL_subclass_t subcls, int opt_type, uint64_t *flags);` | ||
|
||
## Virtual File Layer (VFL) Changes | ||
The virtual file layer has changed in HDF5 1.14.0. Existing virtual file drivers (VFDs) will have to be updated to work with this version of the library. | ||
|
||
## Virtual Object Layer (VOL) Changes | ||
The virtual object layer has changed significantly in HDF5 1.14.0 and the 1.12 VOL API is now considered deprecated and unsupported. Existing virtual object layer connectors shoul be updated to work with this version of the library. |
63 changes: 63 additions & 0 deletions
63
documentation/hdf5-docs/release_specifics/Migrating+from+HDF5+1.8+to+HDF5+1.14.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,63 @@ | ||
--- | ||
title: Migrating from HDF5 1.8 to HDF5 1.10 | ||
redirect_from: | ||
- /display/HDF5/Migrating+from+HDF5+1.8+to+HDF5+1.10.html | ||
--- | ||
|
||
# Migrating from HDF5 1.8 to HDF5 1.10 | ||
|
||
The HDF Group will drop support for HDF5 1.8.* releases in the summer of 2020. We strongly recommend that our users start migrating their applications as soon as possible and we ask that any problems that are encountered be reported to The HDF Group. Problems can be reported by sending email to [email protected], submitting a request to the Service Desk Portal, or posting to the HDF-FORUM. | ||
|
||
Please follow these steps for moving your HDF5 application to HDF5 1.10: | ||
|
||
Make sure the latest (1.1.0.5+) version of HDF5 1.10 is installed on your system. You can download the HDF5 1.10 release source code from The HDF Group Download Portal, and pre-built binaries can be obtained from the Download HDF5 page on The HDF Group web site. Follow the installation instructions. | ||
|
||
If on Unix, you can recompile and relink your application with HDF5 1.10, by using the h5cc script with any compiler flags needed for your application. The h5cc script can be found under the bin sub-directory of the HDF5 1.10 installation point. In cases where your software package has a more complex build system and dependencies, just make sure you point to the new HDF5 1.10.* library when rebuilding your software. | ||
|
||
If your application or software package has any regression test suite, run it and make sure that all tests pass. | ||
|
||
Contact us if you find any problems. | ||
|
||
If you have concerns about the files created by the rebuilt application (or software package), you may wish to consider several verification steps to assure that the files can be read by applications built with HDF5 1.8 releases. | ||
|
||
Use the tools you regularly work with to open, browse, and modify the files created by the rebuilt application (for example, HDFView, MATLAB, IDL, etc.). | ||
|
||
If you have an HDF5 1.8.* installation on your system, use h5dump from that installation to read files created by the rebuilt application. If you encounter any errors, rerun h5dump with the "--enable-error-stack” flag and report the issue. | ||
|
||
If you have files created by your application that were built with HDF5 1.8, use h5diff from the HDF5 1.8 installation to compare with the files created by the rebuilt application. | ||
|
||
If you want to learn more, please see the frequently asked questions (FAQ) below. | ||
|
||
FAQ | ||
What is the difference between the HDF5 1.8 and HDF5 1.10 releases ? | ||
|
||
Many new features (e.g., SWMR, VDS, paged allocation, etc.) that required extensions to the HDF5 file format were added to HDF5 1.10.0. | ||
For more information please see the Release Specific Information pages. | ||
|
||
Why one should (or should not) move an application to HDF5 1.10 ? | ||
HDF5 1.8 will not be supported after the May 2020 release, i.e., there will be no more public releases of HDF5 1.8 with security patches, bug fixes, performance improvements and support for OSs and compilers. | ||
|
||
In addition, applications originally written for use with HDF5 Release 1.8.x can be linked against the HDF5 Release 1.10.x library, thus taking advantage of performance improvements in 1.10. Users are encouraged to move to the latest releases of HDF5 1.10 or to HDF5 1.12.0 (coming out in the summer of 2019) if they want to stay with the current HDF5 upgrades. | ||
|
||
If you are not planning to upgrade your system environment, and a version of HDF5 1.8.* works for you, then there is no reason to upgrade to the latest HDF5. However, if you regularly update your software to use the latest HDF5 1.8 maintenance release, then you need to plan a transition to HDF5 1.10 after the HDF5 1.8 May 2020 release. | ||
|
||
|
||
Why do I need to rebuild my application with HDF5 1.10? | ||
|
||
The HDF5 1.10.* binaries are not ABI compatible with the HDF5 1.8.* binaries due to changes in the public header files and APIs. One has to rebuild an application with the HDF5 1.10.* library. The HDF Group tries hard to maintain ABI compatibility for minor maintenance releases, for example when moving from 1.8.21 to 1.8.22, or 1.10.5 to 1.10.6, but this is not the case when migrating from one major release to another, for example, from 1.8.21 to 1.10.5. If you want to learn more about HDF5 versioning please see HDF5 Library Release Version Numbers. | ||
|
||
Can I migrate my application if I still use the HDF5 1.6 APIs? | ||
|
||
Yes, use the -DH5_USE_16_API compiler flag. For more information see the API Compatibility Macros document. | ||
|
||
Will my old software read files created by an application rebuilt with HDF5 1.10? | ||
|
||
If the application built on HDF5 Release 1.10 avoids use of the new features and does not request use of the latest format, applications built on HDF5 Release 1.8.x will be able to read files the first application created. | ||
|
||
Can I use the HDF5 tools I use now to read files created with the new HDF5 1.10 features? | ||
|
||
Unfortunately, no. However, we provide a few tools that will help you to “downgrade” the file, so it can be opened and used with tools and applications built with the 1.8 versions of HDF5. | ||
|
||
If your application uses SWMR, then the h5format_convert tool can be used to “downgrade” the file to the HDF5 1.8 compatible file format without rewriting raw data. | ||
|
||
The h5repack tool with –l flag can be used to repack VDS source datasets into the HDF5 file using contiguous, chunked or compact storage. The tool can also be used to rewrite the file using the HDF5 1.8 format by specifying the –high=H5F_LIBVER_V18 flag. |
Oops, something went wrong.