Re: How fwrd-compatible is using dlopen and core only?
On 14 August 2018 at 08:57, Pekka Paalanen wrote: > On Fri, 10 Aug 2018 18:31:03 + > ferreiradaselva wrote: > >> 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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: How fwrd-compatible is using dlopen and core only?
On Fri, 10 Aug 2018 18:31:03 + ferreiradaselva wrote: > 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 pgp4ZKAIKq2uG.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: How fwrd-compatible is using dlopen and core only?
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___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
How fwrd-compatible is using dlopen and core only?
Hi, For the OSS window framework that I'm working on, the Wayland backend requires linking to the libraries. No problem here. I wish to give an option to load the Wayland libraries at runtime, using `dlopen()`. The problem is that some functions are inline'd in the headers or part of the extension protocol, but also inline'd. Examples: 1. `wl_registry_add_listener` from `wayland-client-protocol.h` 2. `xdg_surface_ack_configure` from `xdg-shell.h` My question is, how forward compatible my library would be if instead of including those headers, I copy-paste the body content of these functions? Example, I would copy-paste this content from `wl_registry_add_listener` directly to my library: return wl_proxy_add_listener((struct wl_proxy *) wl_registry, (void (**)(void)) listener, data); Since `wl_proxy_add_listener` is a function that I can actually get the pointer using `dlopen()/dlsym()`, I wouldn't require any header. Thanks for the attention, Felipe___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: How fwrd-compatible is using dlopen and core only?
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, _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?___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
