From Fedora Project Wiki

Revision as of 22:24, 28 January 2015 by Xosevp (talk | contribs) (add external links)

Introduction

Checking for changes in Application Binary Interface, or ABI, may be a good idea for a couple of reasons:

  • Upstream does not maintain a soname with version.
  • Upstream is not good about maintaining proper ABI compatibility.

It's important to note that a library's ABI can change even if the API does not. This can happen with internal changes to the compiler and/or compiler flags.

Requirements

It is assumed that you already have a development environment setup which can build packages. Other than that all that is required is the tool abi-compliance-checker.

$ sudo yum install abi-compliance-checker
(or as root)
# yum install abi-compliance-checker

Procedure

abi-compliance-checker has a lot of options and while it's not difficult to use it's not necessarily intuitive either. This example is one way to use the tool and should be considered the best practice.

Step 1: Preparing

First you need to unpack the packages to a location. You can use the these commands directly or add these to a shell script which will be called rpmunpack:

#!/bin/bash

if [ ! -n "$1" ]
then
  echo "Unpacks an RPM into the current directory."
  echo ""
  echo "Usage: `basename $0` <package1> [package2]..."
fi

for file in $*; do
rpm2cpio $file | cpio -idmv
done

Now create a directory structure and unpack the packages:

$ mkdir -p <package>/<version_old>
$ mkdir -p <package>/<version_new>
$ cd <package>/<version_old>
$ rpmunpack <package>-<version_old> <package>-<version_old>-devel
$ cd ../<package>/<version_new>
$ rpmunpack <package>-<version_new> <package>-<version_new>-devel
$ cd ..

Step 2: Dump the ABIs to a file

By default abi-compliance-checker will assign the version based on the directories created previously. If it doesn't get it right use the -vnum option to override it.

Execute the following command for both packages:

$ abi-compliance-checker -l <package> -dump <path to unpacked RPM>

The -l option needs to stay the same for all operations and is the name used in the resultant html report.

Step 3: Compare the to ABI dumps

The ABI dumps will be created in a sub-directory of where abi-compliance-checker was run, abi_dumps/<package>. To compare the to ABI dumps:

$ abi-compliance-checker -l <package> -old abi_dumps/<package>/<package>_<version_old>.abi.tar.gz -new abi_dumps/<package>/<package>_<version_old>.abi.tar.gz

The html report will be created in a directory under compat_reports/<package>/<version_old>_to_<version_new>.

Tips & Tricks

False Positives
abi-compliance-checker is just a tool and doesn't always get it right. The results need to be reviewed as false positives are common. This happens frequently if the old package was compiled with a different version of the compiler or different flags were used. To minimize this, it can be beneficial to rebuild the older package using the same environment as the new package.

ABI dumps error out

This often happens when upstream installs headers for other platforms. Adding the -tolerant option can often work around this problem. As a last resort, simply look through the log and remove the offending header.

External links

Linux Upstream Tracker, API/ABI changes analysis for C/C++ libraries.

ABI compliance checker, tool for checking backward binary and source-level compatibility of a C/C++ library.