Dynamically loading libwayland complications
ideasman42 at gmail.com
Wed Jun 29 02:00:26 UTC 2022
Hi, recently I was looking into dynamically loading libwayland to be
able to support both X11 and Wayland, without requiring libwayland.
For our project is currently a requirement for adopting Wayland.
While I did manage to get this working, use of variadic arguments adds
quite some complexity that could be avoided.
>From what I can tell there is no portable way to wrap
`wl_proxy_marshal_flags` see ,
Using GCC's `__builtin_apply` does work but this isn't available in
CLANG so I'd prefer to avoid it.
The only portable way I found to handle this was to create a header
that needs to be included before any of the headers generated by
wayland-scanner (which make calls to `wl_proxy_marshal_flags`), which
can be replaced by a reference to a function pointer instead of
requiring the function to exist and link at build time.
This is quite messy and means it's not practical to create an isolated
dynamic loader for libwayland-client.
There are a few possible solutions to this but they involve additions
to wayland API.
- Make wl_argument_from_va_list public,
so wrapper functions can always construct `wl_argument` from `va_list`
and forward that to the `wl_argument` version of functions.
- Have va_list versions of all functions (similar to printf/vprintf).
- The ability to retrieve the number of arguments a function expects
would also allow wrappers
to forward `va_args`, although it's fairly obscure.
- Support for wayland-scanner generating code that doesn't call
This is more of a workaround, but would at least mean that projects could
call into alternative versions of the functions.
As far as I can see, exposing `wl_argument_from_va_list` is the most
Would the Wayland project consider tweaks to the API that make
dynamically loading libwayland libraries possible?
More information about the wayland-devel