Binary compliance validation
I'm writing to present an ABI compliance check mechanism for Poky
recently developed to help improve the product stability. It is still
an early work which however has already proven itself useful and thus
the time seems right to ask for the community view.
Binary compliance is an important metric, when a distrubition intends
to provide stability guarantees to consumers outside the monolithic
image build. For example, projects utilizing the SDK might not be in
sync with the image builds from even the same branch. Even in stable
branches where bugfixes, security patches or even non breaching
upgrades have to flow in as necessary, there's is currently no
verifiable mechainsm to ensure the binary compatibility long term.
The currently implemented validation is based on libabigail and as such
is focused on the ABI compliance. Libabigail is a tool developed by Red
Hat and is in use for Fedora and RHEL RPM builds. Some companies are
known to utilize libabigail to support the kernel maintanance (Linux
kernel for Android). The meta layer contains a bbclass extending the
buildhistory functionality with the ABI serialization and comparison.
One buildhistory version taken as a baseline would serve the comparison
with any follow up builds. The ABI changes detected are then reported.
The handling routines in Poky are currently attached to the install
task, which implies the baseline build needs to take place with the
sstate disabled. The follow up buids can use sstate and in that case
the postinstall routines will be invoked only if some change took place
and thus do_install has been called.
The implementation is made as a core Python module, which can be used
in a Yocto layer or imported in any other script. The layer is
and the accompanying python module (which moves at some faster pace and
is synchronized into the layer) and a command line tool:
The layer is yet an early work and the impluementation doesn't exhaust
all the possible features of Poky and libabigail. However, it already
proves itself helpful and is used for some real products to esure the
ABI stability. Certainly the mechanisms and the integration can be
The future for this layer is open containing at least the topics below:
- Binary size auditing.
- Security auditing.
As a shorter term serviceableness, the ABI compliance validation
mechanism seems to be a useful tool in helping to keep promises on LTS,
but would most likely also help maintaining non LTS branches. It would
be great to receive any feedback, reviews and ideas in regard to meta-