Discussion:
How fwrd-compatible is using dlopen and core only?
ferreiradaselva
2018-08-10 16:55:32 UTC
Permalink
Another thing that I realized:

Headers, such as `wayland-client-protocol.h`, contains declarations such as `wl_registry_interface`, which is an extern variable. If I am going to copy-paste this:

wl_proxy_marshal_constructor((struct wl_proxy *) wl_display, WL_DISPLAY_GET_REGISTRY, &wl_registry_interface, NULL);

into my source-code (in order to make my project header-independent), what should I do with `wl_registry_interface`? Should I just define my own `wl_registry_interface` in my source-code to get rid of the header dependency?
ferreiradaselva
2018-08-10 18:31:03 UTC
Permalink
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?

I'm sorry about the sequential e-mails.

Felipe
Pekka Paalanen
2018-08-14 07:57:27 UTC
Permalink
On Fri, 10 Aug 2018 18:31:03 +0000
Post by ferreiradaselva
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.


Thanks,
pq
Emil Velikov
2018-08-14 09:47:32 UTC
Permalink
Post by Pekka Paalanen
On Fri, 10 Aug 2018 18:31:03 +0000
Post by ferreiradaselva
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]

HTH
Emil

[1] https://github.com/waffle-gl/waffle/blob/master/src/waffle/wayland/wayland_wrapper.h
[2] https://github.com/waffle-gl/waffle/blob/master/src/waffle/wayland/wayland_wrapper.c
[3] https://github.com/waffle-gl/waffle/blob/master/src/waffle/wayland/wayland_window.c#L31
Thiago Macieira
2018-08-14 23:31:35 UTC
Permalink
Post by Pekka Paalanen
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.
Except for inline functions that call non-inline functions. If you use one of
those in your application or library, then you will have to link to
libwayland.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
Loading...