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

[Pekka Paalanen]

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:
> 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? (*)

> 
> B) with NEEDED, aka Requires: libwayland-util
>  - Existing binaries will work, if we don't bump version-info
>  - Newly build/linked binaries will fail to run with older wayland -
> regardless of version-info.
> 
> If version-info is bumped, one should use 4:0:0 for wayland-client and
> 2:0:0 for wayland-server, to reflect the backward incompatible change.
> 
> TL;DR; It can be forward or backward compatible, but not both.
> Note that even GLIBC does not guarantee compatibility in both directions.

Right, personally I have not considered the case of building against
new, running against old library binaries to be worthwhile supporting,
but if I understood Daniel's comments he was concerned about that.

Ok, I suppose these are the reasons you propose option B.

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

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

> At the same time it's somewhat frustrating, when you've spent days
> debugging similar issues in the past. Yet people state that it won't
> be a problem :-\

I just didn't understand how these can become a problem in this
specific case. I still don't.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170404/7e430917/attachment.sig>