A New Tool For Tracking ABI Changes Of Libraries

[phoronix]

Phoronix: A New Tool For Tracking ABI Changes Of Libraries

Andrey Ponomarenko has announced his work on ABI-Tracker, a new open-source tool for tracking ABI changes of C/C++ software projects...

http://www.phoronix.com/scan.php?page=news_item&px=LVC-ABI-Tracker-Tool

[brownsr]

and what exactly is ABI tracking ?

[Ancurio]

I looked at some of the stuff it found in cairo, mostly what appear to be false positives I think. It tracked __unknown__(4 byte) being replaced with an unsigned int that's also 4 bytes big in some function parameter and declared it an ABI break, although I'm not sure what exactly happened there.

Also in GTK+, it reported a struct change as an ABI break, even though you never actually access or allocate it directly.

[raster]

I looked at some of the stuff it found in cairo, mostly what appear to be false positives I think. It tracked __unknown__(4 byte) being replaced with an unsigned int that's also 4 bytes big in some function parameter and declared it an ABI break, although I'm not sure what exactly happened there.

Also in GTK+, it reported a struct change as an ABI break, even though you never actually access or allocate it directly.

These are tools - not perfect tools. They HELP find ABI issues. This is like coverity - or even compiler warnings. they are not always right, but often are, and require a human to "inspect". We've been using such ourselves for a while now:

https://devs.enlightenment.org/~tasn/abi/

it's the same core tool - but run manually at release time. unlike the tool, us humans know which symbols make up the public api, and which are a "brewing new beta api" and which are simply things exposes because they have to be to have one library of yours dig into the internals of another, but as you release both at the same time and require their versions to be synced... it is not a problem.

so like many tools - it's a something for your war chest when you go to release to double check and point out possible issues, and then you take them with a grain of salt and release when you know the coast is clear, and not if some tool just dumbly has to pronounce you 100% compatible.

using this tool for a few years has helped us find a few issues here and there before release, so it's actually useful.

[Ancurio]

These are tools - not perfect tools. They HELP find ABI issues. This is like coverity - or even compiler warnings. they are not always right, but often are, and require a human to "inspect". We've been using such ourselves for a while now:

https://devs.enlightenment.org/~tasn/abi/

it's the same core tool - but run manually at release time. unlike the tool, us humans know which symbols make up the public api, and which are a "brewing new beta api" and which are simply things exposes because they have to be to have one library of yours dig into the internals of another, but as you release both at the same time and require their versions to be synced... it is not a problem.

so like many tools - it's a something for your war chest when you go to release to double check and point out possible issues, and then you take them with a grain of salt and release when you know the coast is clear, and not if some tool just dumbly has to pronounce you 100% compatible.

using this tool for a few years has helped us find a few issues here and there before release, so it's actually useful.

I know, I know, just wanted to point out that it's not 100% perfect as the task at hand isn't fully solvable by a (simple) algorithm. But doesn't that incite some cool ideas in your head? For example, how about a tagging system the tool can recognize. You'd tag a function as "<alpha> // might change or disappear again" that the tool would recognize and not count as ABI breaks, or for the struct case I pointed out, "<members-private> // don't access members or allocate this yourself, use new_struct() functions", which would also inhibit changes in the struct from triggering ABI break. And it would be such amazing documentation for humans at the same time.

[Ansla]

How about using a language designed for OOP in the first place? In C++ you have private members, private constructors to prevent someone from manualy allocating a class, and it's a lot more readable too.