On Mon, 3 Apr 2017 19:31:50 +0100 Emil Velikov <[email protected]> wrote:
> On 21 March 2017 at 10:05, Pekka Paalanen <[email protected]> wrote: > > On Mon, 20 Mar 2017 18:21:53 +0000 > > Emil Velikov <[email protected]> wrote: > > > >> On 17 March 2017 at 13:32, Pekka Paalanen <[email protected]> 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
pgp6cRhi2ubqv.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
