Dynamically loading libwayland complications
ppaalanen at gmail.com
Wed Jun 29 08:13:05 UTC 2022
On Wed, 29 Jun 2022 13:41:24 +1000
Campbell Barton <ideasman42 at gmail.com> wrote:
> On Wed, Jun 29, 2022 at 12:38 PM Thiago Macieira <thiago at kde.org> wrote:
> > On Tuesday, 28 June 2022 19:00:26 PDT Campbell Barton wrote:
> > > 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.
> > Simplify your problem by dynamically loading a plugin that links to
> > libwayland, instead of dynamically loading libwayland.
> Right, this is an option, but a much bigger change on our end.
> > > 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.
> > How is this different from any other function from libwayland, variadic or not?
> > If your code isn't linking to libwayland, then it can't call any of those
> > functions. Therefore, you must be using a code generator that is calling
> > something other than those functions.
> Those functions are defined locally, when wayland is present -
> function pointers are set which the local functions call into.
> The complication with variadic functions is there isn't a portable way
> of forwarding the arguments to the dynamically loaded wayland versions
> as none of them take a `va_list`. They all take either `...` or
> As the function to convert `va_list` into `wl_argument` is private, I
> don't think there is a way to forward a `va_list` currently.
Probably all language bindings to non-C-compatible languages have hit
the same problem, which is why the parallel binding API using
wl_argument was added. The code generators for non-C languages use that
API instead of the variadic API. It's just that wayland-scanner itself
is still using the variadic API.
Instead of exposing wl_argument_from_va_list() a more "clean" solution
would be to have a code generator for C using the wl_argument API. I
bet several projects would be happy to use that, if they haven't
implemented it already.
At least personally I would be open to the idea of getting such a
generator into upstream libwayland. I wonder what others would think?
There are more things that might be nice to do differently from
wayland-scanner, but would break the way wayland-scanner generated
files are used, so needs to be either a separate tool or a separate
mode in wayland-scanner.
Having to generate and use a .c file in addition to headers is one
such inconvenience, but I'm not sure how easy that would be to get rid
If the new generator was written in, say, Python, like Meson is which
we already use, then we'd avoid a lot of inconvenience for cross-builds
if you can skip building wayland-scanner for the build architecture and
then how to find that when building stuff for the host architecture.
The new generator could also take the dynamic loading problem into
account from the start, and offer easy ways to use custom function
pointers instead of directly calling the libwayland functions.
Taking the Python idea even further, libwayland could offer a Python
module for parsing and validating Wayland XML files, and offer an API
for writing custom code generators more easily for any language. And
not just for language bindings but documentation generators, too.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel