# C/C++: ABI stability and binary compatibility between "patch" versions

**URL:** <https://forum.hdfgroup.org/t/c-c-abi-stability-and-binary-compatibility-between-patch-versions/5312>\
**Category:** HDF5 Library\
**Created:** [January 21, 2019, 2:49pm UTC](https://forum.hdfgroup.org/t/c-c-abi-stability-and-binary-compatibility-between-patch-versions/5312 "2019-01-21T14:49:49Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![alexander.korsunsky](https://forum.hdfgroup.org/letter_avatar_proxy/v4/letter/a/ecc23a/32.png) [@alexander.korsunsky](https://forum.hdfgroup.org/u/alexander.korsunsky)\
**Post date:** [January 21, 2019, 2:49pm UTC](https://forum.hdfgroup.org/t/c-c-abi-stability-and-binary-compatibility-between-patch-versions/5312/1 "2019-01-21T14:49:50Z")

</div>

tl;dr: what’s up with ABI stability?

Hi there!

To my surprise, I recently discovered that contrary to popular software development conventions, the releases of the same “minor” version of HDF5 but different “patch” version are **not** binary compatible with each other.

This causes major grievances for packagers like Linux distributions. For example, the HDF5 version of CentOS - a Linux distribution that’s popular with many scientists - will forever[[1]](https://bugzilla.redhat.com/show_bug.cgi?id=1666736#c3) stick with HDF5 version 1.8.12, which is 5 years old at the time of writing.  
The reason is that a bump in the version would require a rebuild of _all_ the dependent packages in the EPEL repository.

When redistributing HDF5 along with a binary application, this also effectively locks the application out of all bugfixes and security fixes that may have been released after the original version.

In June 2016 (now 2.5 years ago) @epourmal has acknowledged[2] that the issue is of “high priority” and that they "will get back to it after all features planned for 1.10.0 are finally out ". Are there any updates regarding binary compatibility?

After checking out the ABI stability tracker for HDF5 [[3]](https://abi-laboratory.pro/?view=timeline&l=hdf5) that was created by another user of this forum [[4]](https://forum.hdfgroup.org/t/binary-compatibility-report/3806), it seems that the ABI has mostly stabilized. Are there official statements, or statements in the documentation about the ABI compatibility between versions?

[1] [https://bugzilla.redhat.com/show\_bug.cgi?id=1666736#c3](https://bugzilla.redhat.com/show_bug.cgi?id=1666736#c3)  
[2] [HDF5\_DISABLE\_VERSION\_CHECK and disable\_version\_check](https://forum.hdfgroup.org/t/hdf5-disable-version-check-and-disable-version-check/3795/5)  
[3] [https://abi-laboratory.pro/?view=timeline&l=hdf5](https://abi-laboratory.pro/?view=timeline&l=hdf5)  
[4] [Binary compatibility report](https://forum.hdfgroup.org/t/binary-compatibility-report/3806)

---

<div class="post-metadata">

**Author:** ![paramon](https://forum.hdfgroup.org/letter_avatar_proxy/v4/letter/p/8491ac/32.png) [@paramon](https://forum.hdfgroup.org/u/paramon)\
**Post date:** [January 21, 2019, 9:24pm UTC](https://forum.hdfgroup.org/t/c-c-abi-stability-and-binary-compatibility-between-patch-versions/5312/2 "2019-01-21T21:24:36Z")

</div>

Hi Alexander,

HDF5 users share your disappointment!

I have reported the problem recently:

> [@HDFView 3.0 Pre-release - Newsletter #163 - The HDF Group](https://forum.hdfgroup.org/t/hdfview-3-0-pre-release-newsletter-163-the-hdf-group/4686/2):
>
> Hello! Just tried to update from HDF5 10.1 to HDF5 10.4 in my codebase, and apparently HDF5 release 10.3 did break library API compatibility. Specifically, functions H5Oget\_info, H5Oget\_info\_by\_idx, H5Oget\_info\_by\_name, H5Ovisit, H5Ovisit\_by\_name are now available either with new definition (suffixed with 2) or with original definition (suffixed with 1), but never by original name (without suffix). Older client code relying on original names will break, as confirmed by e.g. [https://github.com/…](https://github.com/JuliaIO/HDF5.jl/issues/508)

Hopefully it’s fixed in 1.10.5, so that lost symbols get back.

Best wishes,  
Andrey Paramonov

---

<div class="post-metadata">

**Author:** ![epourmal](https://forum.hdfgroup.org/letter_avatar_proxy/v4/letter/e/c67d28/32.png) [@epourmal](https://forum.hdfgroup.org/u/epourmal)\
**Post date:** [January 22, 2019, 5:03am UTC](https://forum.hdfgroup.org/t/c-c-abi-stability-and-binary-compatibility-between-patch-versions/5312/3 "2019-01-22T05:03:44Z")

</div>

Aleksandar, Andrey and All,

In HDF5 1.10.4 we made a mistake with H5Oget\_info\* and introduced new binary compatibility issues. We didn’t acknowledged the mistake on FORUM, so I am doing it now and apologize for our slow response.

We will revert the H5Oget\_info\* changes in 1\_10 branch and in the upcoming 1.10.5 release.

It is very unfortunate that the mistake was reported **after** the 1.10.4 release.

The community and especially package and software stacks maintainers, could help us by testing the release candidates. We post on FORUM when a release candidate is available and your timely feedback is highly appreciated. When we don’t hear from you, we assume that everything is working.

We discussed [2] internally, but the issue for maintenance releases is still not resolved. Any volunteers to work on it with us?

Thank you!

Elena

---

<div class="post-metadata">

**Author:** ![paramon](https://forum.hdfgroup.org/letter_avatar_proxy/v4/letter/p/8491ac/32.png) [@paramon](https://forum.hdfgroup.org/u/paramon)\
**Post date:** [January 22, 2019, 8:37am UTC](https://forum.hdfgroup.org/t/c-c-abi-stability-and-binary-compatibility-between-patch-versions/5312/4 "2019-01-22T08:37:32Z")

</div>

Hi Elena,

And thank you for your comments!

> It is very unfortunate that the mistake was reported _after_ the 1.10.4  
> release.
> 
> The community and especially package and software stacks maintainers,  
> could help us by testing the release candidates. We post on FORUM when a  
> release candidate is available and your timely feedback is highly  
> appreciated. When we don’t hear from you, we assume that everything is  
> working.

I am sorry that the problem was reported with a large time lag; in the  
future I will try to pay more attention to RC announcements.

At the same time, this particular issue was reliably caught by robots.  
Might it be possible that ABI stability checks are integrated into  
release testing procedure, or even continuous integration system?

Best wishes,  
Andrey Paramonov
