cannot create opengl by dynamically loading wayland symbols from library

[Pekka Paalanen]

On Wed, 16 Apr 2014 14:45:20 -0500
Jason Ekstrand <jason at jlekstrand.net> wrote:

> On Apr 16, 2014 2:01 PM, "Jasper St. Pierre" <jstpierre at mecheye.net> wrote:
> >
> > On Wed, Apr 16, 2014 at 2:27 PM, Pekka Paalanen <ppaalanen at gmail.com>
> wrote:
> >>
> >> Btw. if the generated inline wrapper functions do not suit you, I
> >> think you could generate your own from the XML files, that end up
> >> calling the real functions exported from libwayland-client. That is
> >> how bindings to other programming languages are supposed work to my
> >> understanding.
> 
> You are more than welcome to write your own protocol parser that dumps out
> something that uses function pointers.  That should be a fine way to do
> it.  However, if you do so, you will want to use the
> wl_proxy_do_something_array versions such as
> wl_proxy_marshal_constructor_array.  These take an array of things of the
> type wl_argument instead of variable argument lists.  These should dlsym
> nicely.  If you want, you could write nice variable-argument wrappers that
> internally call your function pointers that call the _array version of the
> corresponding function.  (That's actually what libwayland does sans the
> function pointers part.)
> 
> > This won't work with EGL, as EGL expects libwayland-client. It's the same
> issue with X11: you can't just use XCB because GLX expects Xlib's Display /
> Window pointers.
> 
> As long as they're still using libwayland-client and passing around
> wl_proxy structures and not re-implementing the wire protocol, it should
> work fine.

Yup, the point was to still use libwayland-client for everything, but
replace the inline wrapper functions, which would get built into your
application binary anyway. Those are not exported from
libwayland-client.so, they are only in the (generated) headers.

And you should still be able to use the exported wl_interface symbols
from libwayland-client.so, too, I think, since regenerating those could
be an additional chance for error in one's own protocol spec parser.


Thanks,
pq