On Wed, Jun 29, 2022 at 12:38 PM Thiago Macieira <thi...@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 [0], > > 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 `wl_argument`. 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. > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > Software Architect - Intel DPG Cloud Engineering > > > -- - Campbell
