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

[Emil Velikov]

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

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

>> 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

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 :-)

Cheers,
Emil

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