[PATCH wayland] wayland-egl: Ignore underscored symbols in ABI check

[Emil Velikov]

On 20 March 2018 at 11:46, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi Emil,
>
> On 20 March 2018 at 11:30, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 20 March 2018 at 11:01, Daniel Stone <daniels at collabora.com> wrote:
>>> Rather than a hard-coded list of platform symbols, just ignore anything
>>> prefaced with an underscore. This fixes breakage on ARM, which declares
>>> several slightly different platform symbols to x86.
>>
>> FWIW I've explicitly opted against this kind of heuristics for a few reasons:
>>
>>  - projects use single/double underscored symbols for internal API
>>  - other projects have been using such symbols knowingly that it's internal API
>> Last but not least
>>  - the symbols exposed by the C runtime should stay stable
>>
>> In other words - prevents others from going silly things, only the
>> list might need 1-2 updates.
>> If the latter turns out to be false we can nuke it.
>
> Sure. As on IRC though, we definitely need to add at least _ftext for
> MIPS anyway:
> https://gitlab.gnome.org/GNOME/glib/commit/ad12142943e0f20ed9583c9d6bf50f6262110c74
>
> And probably some more for ARM toolchains using other linkers:
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0474k/pge1362066045758.html
>
> Doing a quick check across all the architectures on Debian shows that
> your updated list is also missing _fbss, _fdata, and _ftext. So we'd
> need to respin for those as well, but I think at this point the
> inconvenience of maintaining a list of every linker's implementation
> detail on every platform, outweighs the risk of an exported
> underscore-prefixed symbol slipping through review.
>
I think you're preemptively worried about this. Plus there's no need
to add every symbol a search could find.

Even then, ask yourself the question:
Which is better - updating an ugly looking list once in a blue moon or
having apps use internal API?

As said above: _if_ it turns out to be labour intensive - fine remove it.
We've already spend more time researching than what the [expected]
maintenance for 1 year would be ;-)

-Emil