On 15 September 2017 at 15:13, Daniel Stone <dan...@fooishbar.org> wrote: > Hi, > > On 15 September 2017 at 14:30, Emil Velikov <emil.l.veli...@gmail.com> wrote: >> On 15 September 2017 at 14:04, Daniel Stone <dan...@fooishbar.org> wrote: >>> I'd be slightly wary of this current series. Currently, both >>> libwayland-server.so and libwayland-client.so define >>> wl_buffer_interface separately: >>> strictly:~/misc/visa% objdump -x >>> ~/prefix/wayland/lib/libwayland-server.so.0.1.0 | grep wl_buffer_int >>> 0000000000212e40 g O .data.rel.ro 0000000000000028 >>> wl_buffer_interface >>> strictly:~/misc/visa% objdump -x >>> ~/prefix/wayland/lib/libwayland-client.so.0.3.0| grep wl_buffer_int >>> 000000000020dea0 g O .data.rel.ro 0000000000000028 >>> wl_buffer_interface >> >> Right, I tried to address that but there were some objection from >> yourself/Pekka. > > Kinda, yes. I was certainly against breaking our ABI in order to not > export the symbols; it would've been great if they weren't exported > originally, but they are and we just have to live with it until we > decide that we want everyone using Wayland to change their code and > build system and recompile in one big flag day. > > But if you avoid wl_resource_instance_of() and replace it with > wl_resource_get_destroy_listener(), you can side-step the problem, by > not relying on consistent resolution of wl_buffer_interface. That's a > real bugfix. :) > Right, I'm looking through both functions and I'm struggling a bit. Can I bother you with sending a patch?
>>> I'll grant you that it's basically pot luck as to which one is >>> resolved first, but if we remove the wayland-server linkage, it seems >>> more prone to pick the wayland-client interface, i.e. the wrong one. >>> >>> Changing the wl_resource_instance_of() call into >>> wl_resource_get_destroy_listener() would be far more foolproof, but it >>> doesn't remove the need for linkage. >>> >> The patch removes the libwayland-drm.la linkage, not the >> wayland-client/server one. >> I don't think it makes sense to remove the wayland-server link for >> gbm, since it's (sort of) a server. >> >> The original confusion is (hopefully) unwrapped with the next patch - >> where users are linked only against what they should. >> Namely, as wayland platform is selected: >> >> libgbm -> libwayland-server >> libEGL -> libwayland-client + libwayland-server if drm/gbm platform is >> toggled. >> Last one is for the eglBindWaylandDisplay EGL <> GBM interop with wl_drm. > > Nested compositors rely on eglBindWaylandDisplayWL() as well: if you > start Weston under a Wayland compositor, it will call > BindWaylandDisplay in order to export acceleration to its own clients. > So even if the DRM/GBM Wayland platform isn't active, libEGL should > still be linked to libwayland-server, unfortunately. > Ehh... sounds like we a bug in libEGL ;-) This patch cleans up some unneeded inter-dependencies, as a bonus making libgbm.so ~3KiB smaller. It'll be great to have but nothing crucial really. -Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev