[PATCH wayland 0/4] Untangle the symbol export duplication

[Pekka Paalanen]

On Tue, 30 Aug 2016 18:24:18 +0100
Emil Velikov <emil.l.velikov at gmail.com> wrote:

> Hi all,
> 
> For a while I've noticed that on mesa side we have few providers of the 
> wl_drm_interface symbol and literally all our 'wayland binaries' are 
> linked against both the client and server wayland libs.
> 
> After having a look, it seems that:
>  - the server exposes the interface symbols for 'inheritance' purposes, 
> thus other servers can build upon these primitives while designing their 
> own protocols (interfaces ?).

I have no idea what that means. wl_drm is private to Mesa.

You are not supposed to use wl_drm in your apps, and *no-one* is
supposed to build on it by any other way than copying the XML file and
renaming everything. The recommended way would be to start writing XML
from scratch though.

>  - at the same time the client needs to have a reference to the 
> interface symbol in order to register an instance of said interface.

Anyway, those details don't really matter at all, see below.

> This means that if the "wrong" symbol gets picked at runtime and the 
> client does not correctly manage older versions in its 
> .registry_handle_global function (yes we have a case or two of those in 
> the wild) things will end up horribly wrong.
> 
> I think that a better option would have been to distinguish the two 
> (call one instance or the other singleton) and let the scanner attribute 
> for the name difference. Regardless of that is that it's too late to 
> change things since this would lead to breaking the ABI.
> 
> One way around it to update the scanner to provide newer symbols and 
> annotate the old ones as deprecated. This way when/if we break the ABI 
> we can untangle things. One day...
> 
> Does the above sound about right - can anyone let me know if I'm loosing 
> the plot ?
> 
> That said, I've went ahead and removed duplication where possible - by 
> folding the util symbols into libwayland-util. Please check with patch 3/4 
> how compatibility with existing and new users is be preserved.

Actually, the <foo>_interface symbols are not meant to be exported *at
all*. But there is a catch that is the source for all the confusion.

For historical reasons, libwayland-server and libwayland-client are
designed to export the wl_*_interface pointers, because libwayland
ships the headers generated from wayland.xml. The headers cannot work
if something does not provide the symbols from the generated
wayland-protocol.c file. IMHO and in hindsight, this was a mistake - we
should have installed only the XML file and require everyone to
generate their own wayland.xml bindings to keep things consistent. But,
it's done, and now it is API and ABI, so we cannot change that.

That is the reason why wayland-scanner emits all the WL_EXPORTs in the
*-protocol.c file. IMO it really should not do that, except for
wayland.xml itself only when building libwayland.

It's an unfortunate accident that all libs using Wayland extensions
from wayland-protocols or anywhere are exporting the *_interface
symbols. There is really no need for that as I see. If two pieces of
software use the same extension, they can just (generate and) build in
their own copies of the *-protocol.c file.

Libwayland has been written to cope just fine with multiple copies of
interface definitions, or it at least should.


I would seriously suggest that we make wayland-scanner *not* emit any
WL_EXPORTs for the *-protocol.c file if at all possible. I would like
that to be the default, while libwayland build would opt-in for the
exports.

Can we do that, or would it break any ABI we actually care about?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160914/1edae24c/attachment.sig>