On the other hand the vtable of class X in libfoo.so.4 contains X::~X() pointer at the same offset (16):
16 (int (*)(...)) X::~X()
However abi-compliance-checker declares these ABIs to be compatible. It correctly points out that the size of X's vtable changed, and warns that "Call of any method in this class may result in crash or incorrect behavior of applications." Indeed the app which expects to find &X::foo at offset 16 will definitely crash.
Any reordering of vtable (except appending new entries) should be reported as a High severity problem.
Consider two binary incompatible versions of the class X: https://github.com/asheplyakov/libfoo/blob/v0/include/foo/foo.h#L11-L17 https://github.com/asheplyakov/libfoo/blob/v4/include/foo/foo.h#L22-L29
These classes have the following vtables:
In particular the vtable of class X in
libfoo.so.0
contains X::foo pointer at offset 16:16 (int (*)(...)) X::foo(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
On the other hand the vtable of class X in
libfoo.so.4
contains X::~X() pointer at the same offset (16):16 (int (*)(...)) X::~X()
However abi-compliance-checker declares these ABIs to be compatible. It correctly points out that the size of X's vtable changed, and warns that "Call of any method in this class may result in crash or incorrect behavior of applications." Indeed the app which expects to find
&X::foo
at offset 16 will definitely crash. Any reordering of vtable (except appending new entries) should be reported as a High severity problem.