From Fedora Project Wiki

No edit summary
Line 1: Line 1:
== Introduction ==
== Introduction ==


When a new version of an ELF shared library (that we shall name L) is installed on the system, it's critically important that its [http://en.wikipedia.org/wiki/Application_binary_interface Application Binary Interface] (a.k.a ABI) stays compatible with the ABI of its previous version.  That compatibility ensures that ELF binaries, that [https://en.wikipedia.org/wiki/Linker_%28computing%29 dynamically link] with L, keep seeing the ABI they expect from that library L.  Otherwise, if the ABI of the new version of L is incompatible of with the ABI expected by the binaries that link with it, subtle and sometimes hard to debug runtime errors follow.
When a new version of an ELF shared library (let's call it FOO) is installed on the system, it's critically important that its [http://en.wikipedia.org/wiki/Application_binary_interface Application Binary Interface] (a.k.a ABI) stays compatible with the ABI of its previous version.  That compatibility ensures that ELF binaries, that [https://en.wikipedia.org/wiki/Linker_%28computing%29 dynamically link] with FOO, keep seeing the ABI they expect from that library FOO.  Otherwise, if the ABI of the new version of FOO is incompatible of with the ABI expected by the binaries that link with it, subtle and sometimes hard to debug runtime errors follow.


As maintainers of a package that contains a shared library L, it's our duty to ensure that the ABI of new versions of L stays compatible with the ABI of its former versions.
As maintainers of a package that contains a shared library FOO, it's our duty to ensure that the ABI of new versions of FOO stays compatible with the ABI of its former versions.


Thus, comparing the ABI of the new version of a package against its previous version is critical to detect possible incompatibilities, review them and file relevant bugs upstream, should the need arise.  That comparison should be part of the normal update process followed by maintainers of packages that contain ELF libraries.
Thus, comparing the ABI of the new version of a package against its previous version is critical to detect possible incompatibilities, review them and file relevant bugs upstream, should the need arise.  That comparison should be part of the normal update process followed by maintainers of packages that contain ELF libraries.

Revision as of 17:27, 3 December 2015

Introduction

When a new version of an ELF shared library (let's call it FOO) is installed on the system, it's critically important that its Application Binary Interface (a.k.a ABI) stays compatible with the ABI of its previous version. That compatibility ensures that ELF binaries, that dynamically link with FOO, keep seeing the ABI they expect from that library FOO. Otherwise, if the ABI of the new version of FOO is incompatible of with the ABI expected by the binaries that link with it, subtle and sometimes hard to debug runtime errors follow.

As maintainers of a package that contains a shared library FOO, it's our duty to ensure that the ABI of new versions of FOO stays compatible with the ABI of its former versions.

Thus, comparing the ABI of the new version of a package against its previous version is critical to detect possible incompatibilities, review them and file relevant bugs upstream, should the need arise. That comparison should be part of the normal update process followed by maintainers of packages that contain ELF libraries.

Hands on

Reviewing ABI changes in a given ELF binary

There are essentially two tools to review the ABI differences between two versions of a given ELF binary:

Reviewing ABI changes in a given RPM package

There are two main tools tailored for comparing the ABIs of packages: abipkgdiff and abi-compliance-checker

External links