How fwrd-compatible is using dlopen and core only?

Emil Velikov emil.l.velikov at
Tue Aug 14 09:47:32 UTC 2018

On 14 August 2018 at 08:57, Pekka Paalanen <ppaalanen at> wrote:
> On Fri, 10 Aug 2018 18:31:03 +0000
> ferreiradaselva <ferreiradaselva at> wrote:
>> Oh,
>> I solved the problem with the extern variable
>> (wl_registry_interface), I could get a pointer to it using
>> `dlsym(handler, "wl_registry_interface")`.
>> The other question remains: can I use the content of the inline
>> functions directly (to avoid the need to include protocol headers)?
>> Is forward-compatibility guaranteed?
> Hi,
> yes, you can.
> The inline functions and everything that is in the installed headers of
> libwayland, generated or not, will always get built into user programs.
> We try hard to not break any already compiled user programs (this is
> the promise of a stable library ABI), which means you should be safe.
> The above naturally also applies to headers generated by
> wayland-scanner for extensions from e.g. wayland-protocols. A user
> project may get the XML file from a wayland-protocols dependency, but
> it is only used at build time. Once the user project is built,
> libwayland must guarantee that it will keep working ABI wise.
> I belive e.g. libSDL is already doing what you intend, see
> src/video/wayland/.
> Another design would be to make your own plugin to your library and
> dlopen that plugin which was linked to libwayland during the build as
> usual. Whether that's better or worse depends on your scope.
I would strongly stay away from copying misc inline functions from the
wayland headers.
Instead one can follow the SDL and Waffle (much simpler IMHO)
approach. Here is quick how-to:

- declare mangled symbol pointers, define the normal symbols in terms
of the mangled ones [1]
- have some init function that populates the mangled symbol pointers [2]
- make sure you include the 'wrapper' header before the normal wayland
headers [3]



More information about the wayland-devel mailing list