[PATCH wayland v2 3/4] wayland-util: build/ship as separate shared library

[Emil Velikov]

On 4 April 2017 at 09:08, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Mon, 3 Apr 2017 19:31:50 +0100
> Emil Velikov <emil.l.velikov at gmail.com> wrote:
>
>> On 21 March 2017 at 10:05, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> > On Mon, 20 Mar 2017 18:21:53 +0000
>> > Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> >
>> >> On 17 March 2017 at 13:32, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
>> Summarising the points below. Highlighting the key words - hope it
>> provides some clarity.
>>
>> If we don't bump the version-info:
This line should not be here.

>> A) w/o NEEDED, aka Requires.private: libwayland-util
>>  - Existing binaries _will_ work, as the symbols will be _implicitly_
>> resolved at _runtime_.
>>  - Newly build binaries _may_ (depending on a few factors) fail at _link_ time
>
> Hi,
>
> the latter item in case A is what I do not understand. To me it seemed
> like you were claiming that it does work, now you say it might not. Can
> you explain, please? (*)
>
The key is word here is "runtime" vs "link time".
For A runtime will be fine, while link may not work.


>> >> > Then there is the case of dlopen()'ing these libraries. I think there
>> >> > might be something unexpected to expect because we have this:
>> >> > https://cgit.freedesktop.org/wayland/weston/tree/libweston/compositor-drm.c?id=2.0.0#n1575
>> >> > introduced in commit 97f2952b.
>
>> > The scenario is this:
>> >
>> > Someone writes a plugin (dlopen()'d DSO) for his program (an
>> > executable, or maybe loaded via library). The plugin uses
>> > libwayland-client (pkg-config name) and it uses wl_list API. His
>> > program and the plugin are built with the old libwayland. Then the
>> > Wayland libs get updated to a version including your patch. Now we have
>> > a situation where the program and the plugin do *not* explicitly link
>> > to libwayland-util, yet the plugin uses symbols exported only by
>> > libwayland-util. The plugin is dlopened(). Is this not exactly the same
>> > case as why we have the hack for Mesa in Weston?
>> >
>> FWIW the Mesa design decision was made way before I started any Mesa
>> development.
>> The case you're thinking of is very close yet subtly different from
>> the one we have around Mesa.
>>
>> Here, when the plugin is linked against old wayland, it will have a
>> link against libwayland-client, libwayland-server or both.
>> Regardless of the API it uses.
>>
>> As we plugin is dlopened, the libwayland-client/server dependency will
>> a) resolve the symbol dependency for older wayland or b) pull
>> libwayland-util which will provide the required symbols, in case of
>> newer wayland.
>
> This one place where you seem to say it will work, yet above (*) you
> said it does not always work.
>
We dlopen at runtime, issue described in A is a link-time one.

>> >> > ISTR libSDL dlopen()'s libwayland-client.so which is a slightly
>> >> > different case again.
>> >> >
>> >> Yes, dlopen/dlsym is safe, regardless of who is doing it.
>> >> To explain why/who - as one does dlsym(libwayland-client.so.0_handle,
>> >> "wl_list_goo") the linker will propagate to the direct dependencies
>> >> and if any of those provide the symbol a pointer to it will be
>> >> returned.
>> >
>> > Yes, I hope it works that way too. So what went wrong in Mesa in the
>> > case I referred to?
>> >
>> In Mesa the symbols are not resolved neither directly nor indirectly.
>> Here they are handled directly (old wayland) or indirectly (new
>> wayland).
>
> What does that mean? If in Mesa "[they] are not resolved neither
> directly nor indirectly", then what does it do? What else is there? Is
> this a reference to eglGetProcAddress? If it is, then how did manually
> loading libglapi.so.0 help with it? I'm going to regret asking, aren't
> I? :-)
>
EGL has nothing to do with it.

In order to understand what/why things behave as-is, one needs the
following information.

Both loaders (GBM, EGL, GLX) and drivers (foo_dri) access* to the
GLAPI, since the GLAPI state is shared across APIs and per-thread.
Of which:
 - the drivers use GLAPI but do not link - NEED FIXING
 - GLX uses GLAPI directly and links - SAFE
 - EGL uses dlopen/dlsym to fetch required symbols - SAFE
 - *GBM does not use GLAPI, yet it dlopen the drivers - WORKAROUND in
place since Mesa 10.5.x, for problems you/others have observed.

The above diverse solutions are due to historical and implementation $reasons.

Many early day EGL/GBM users linked or dlopened GLX (libGL.so) latter
of which gets you the GLAPI symbols. Thus using GBM was fine.
As people started shifting away from GLX, the symbols were no longer
provided and people noticed the bug.
For those that use EGL _API_ before the GBM one they won't notice the
bug since libEGL will implicitly resolve the GLAPI symbols, props to
its dlopen(RTLD_GLOBAL)

Hope that provides more clarity, on the whole lovely situation.

Thanks
Emil