[waffle] Update on "Don't explicitly link to libraries - use libdl instead"

[Chad Versace]

On 02/17/2015 03:31 PM, Emil Velikov wrote:
> On 17/02/15 19:34, Chad Versace wrote:
>> On 02/12/2015 05:56 AM, Emil Velikov wrote:
>>> Hello all,
>>>
>>> In case you've been wondering what happened with that here it goes:
>>>
>>> Currently the following libraries could be nuked
>>>
>>>   NEEDED               libwayland-client.so.0
>>>   NEEDED               libwayland-egl.so.1
>>>   NEEDED               libX11-xcb.so.1
>>>   NEEDED               libX11.so.6
>>>   NEEDED               libxcb.so.1
>>>   NEEDED               libudev.so.1
>>>
>>> From the above we're using the following problematic APIs:
>>>
>>> X11/xcb
>>> * XGetXCBConnection
>>>
>>> libwayland-client
>>> * wl_registry_add_listener
>>> * wl_shell_surface_add_listener
>>> * Others ?
>>>
>>> On the X11/xcb side we can fix this by transitioning to a xcb only
>>> implementation, but that means (a) breaking the API/ABI and (b)
>>> updating all the users (with XLookupString being the messiest).
>>
>> We shouldn't break Waffle's X11 API. If you want to expose an XCB-only
>> backend, then it would make sense to add a new platform type,
>> WAFFLE_PLATFORM_XCB_EGL, which shares most of its code with
>> WAFFLE_PLATFORM_X11_EGL.
>>
> Hmm I like the idea of WAFFLE_PLATFORM_XCB_EGL. It will ease the
> transition quite a bit, I will throw it in the Waffle TODO list.
> 
>> Is there any reason why Waffle can't use dlsym() to get XGetXCBConnection?
>>  
> Afaict the general idea of using dlopen/dlsym for libX11/libxcb is
> frowned upon, upon asking in #xorg-devel these are roughly the answers:
> 
>  - Create libwaffle-x11.so backend which links against the lib* and
> dlopen that one in your main library.
>  - Link against SDL, which already dlopen/dlsyms lib*
>  - You should not do this it's bad, and by bad I mean it'll take a lot
> of effort.
> 
> ... all in all no technical reasons behind it.
> 
> Maybe the people which were trying to help had too many bad experiences
> with Xlib so they were trying to save me the headaches :P

Thanks for doing all this research. Xlib is old, and the memory of the
painful havoc it wreaks on those foolish enough to trust it is slow to
fade.

> Either way I will give it a try and see how badly things behave.

I really don't understand how dlsym'ing XGetXCBConnection is a bad idea...
Let's just give it a try, and prepare for the future regrets!

>>> Why problematic - the functions are defined as "static inline" within
>>> the respective headers, which means that they are expanded during
>>> compilation. My biggest concern is that (imho) there is no guarantee
>>> by either library that the current implementation will stay the same,
>>> thus we cannot manually inline them in waffle.
>>>
>>> Should be bite the bullet and do it anyway ? Does anyone know a lovely
>>> trick to resolve this ?
>>
>> There is an easy way to dlsym() the Wayland functions. The inline protocol functions
>> in wayland-client-protocol.h are all implemented by real library calls to wl_proxy_* functions.
>> The wl_proxy functions *do* have stable ABI. So, to stop linking to libwayland-client,
>> for each wl_proxy function used by wayland-client-protocol.h (there's about a dozen),
>> Waffle needs to provide its own definition of the wl_proxy function that forwards its
>> arguments to a dlysm() wl_proxy function. Like this:
>>
>> void
>> wl_proxy_add_dispatcher(struct wl_proxy *proxy, wl_dispatcher_func_t dispatcher_func,
>>                         const void *dispatcher_data, void *data)
>> {
>>     // This is a function pointer dlsym'd during waffle_init().
>>     wfl_wl_proxy_add_dispatcher(prox, dispatcher_func, dispatcher_data, data);
>> }
>>
> Upon closer look adding wrappers might not be our biggest concern, but
> the data symbols we reference in waffle:
> 
> $ objdump -CtT libwaffle-1.so | grep "wl_.*_interface"
> 
> wl_surface_interface
> wl_shell_surface_interface
> wl_compositor_interface
> wl_registry_interface
> wl_shell_interface

Why are these more of a concern than the inline wrappers? dlsym works on all
public symbols, including variable symbols. Am I missing something?
 
> There is some input from Pekka (pq) in the dri logs [1] around 06:52.
> But until we get that far, I'll be looking and testing the libX11/libxcb
> side(lack) of things :-)

> [1] http://people.freedesktop.org/~cbrill/dri-log/?channel=wayland&date=2015-02-13

I read the logs. Let me explain some more...

Re-implementing all the wrapper functions will be a big pain, for all the reasons
described in irc. But I wasn't suggesting that. I was suggesting that we dlsym
all the real, non-inline functions called by the inline functions in wayland-client-protocol.h,
and #include wayland-client-protocol.h as-is. As in the example code below.

When linking libwaffle at buildtime, all the symbols called by the inline
waffle-client-protocol.h functions will be defined by libwaffle itself.

// ------------------------
// file: wayland-wrapper.h

#include <wayland-client.h>

// This function pointer is dlsym'd during waffle_init().
extern void
(*wrapped_wl_proxy_add_dispatcher)(struct wl_proxy *proxy, wl_dispatcher_func_t dispatcher_func,
                                   const void *dispatcher_data, void *data);

void
wl_proxy_add_dispatcher(struct wl_proxy *proxy, wl_dispatcher_func_t dispatcher_func,
                        const void *dispatcher_data, void *data);

// ------------------------
// file: wayland-wrapper.c

#include "wayland-wrapper.h"

void
(*wrapped_wl_proxy_add_dispatcher)(struct wl_proxy *proxy, wl_dispatcher_func_t dispatcher_func,
                                   const void *dispatcher_data, void *data);

void
wl_proxy_add_dispatcher(struct wl_proxy *proxy, wl_dispatcher_func_t dispatcher_func,
                        const void *dispatcher_data, void *data)
{
    wrapped_wl_proxy_add_dispatcher(prox, dispatcher_func, dispatcher_data, data);
}

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/waffle/attachments/20150217/95f42206/attachment-0001.sig>