Detailed symbols.map

[Daniel van Vugt]

That's the problem. We don't have abi-check automated yet. Although we 
don't have to limit ourselves to that.

What we do have is regular ABI breaks landing and nobody noticing. So I 
audit the code manually and propose the missing breaks. Fortunately the 
whole team is getting on board and noticing them more often, but it's 
still not automated.


On 27/08/15 11:26, Christopher James Halse Rogers wrote:
> On Thu, Aug 27, 2015 at 12:05 PM, Daniel van Vugt
> <daniel.van.vugt at canonical.com> wrote:
>> 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.
>
> I'm not entirely sure what problem you're trying to solve here? We
> regularly break - and bump - ABIs, and that's fine.
>
> We *also* have the abi-check target which is strictly better than
> symbols.map at finding these things - it also finds structure size
> changes and enumeration numbering differences, for example.
>
> We've talked about having abi-check run as an advisory test on all MPs
> for a while. Now that JaaS is mostly here, maybe that would solve the
> problem?
>