Detailed symbols.map

[Daniel van Vugt]

That's true. If someone adds a field to a struct or changes the size of 
a bool, symbol names don't change. Even worse; how do you communicate 
that myprojectN uses libstdc++M? In a past life I actually went to the 
trouble of putting out different binary releases for libc5 systems vs 
libc6. So another hidden part of your ABI is "what other C/C++ library 
ABIs does it depend on?".

What I've been suggesting however is aimed at solving precisely the kind 
of ABI break that mir-team keeps landing and reviewers not noticing.


On 26/08/15 18:24, Stephen M. Webb wrote:
> On Wed, Aug 26, 2015 at 5:40 AM, Daniel van Vugt
> <daniel.van.vugt at canonical.com> wrote:
>> I guess the way we want to and should maintain ABIs is that the contents of
>> a stanza MIR_SERVER_N { } never changes (although you can always add a new
>> stanza MIR_SERVER_N+1 with changes). So store a historical copy of existing
>> "ABIs" such as MIR_SERVER_N and compare to make sure its contents never
>> change (if still present at all).
>
> That's how libstdc++ does it, and they've done a pretty good job of
> maintaining ABI copatibility for about 15 years (GCC-5
> notwithstanding: sometimes you just have to break ABI).  This has to
> be done in conjunction with an additional check tool, though, which is
> why a symbols version file is used in the sources *and*
> dpkg-gensymbols is used in the packaging on Debian-based systems.
> Libstdc++ actually uses its own tool during the build to look for
> missing symbol changes at build time.
>
> This is a false security, though, because most of the insidious ABI
> changes do not show up as symbol name changes.
>