On 17 March 2017 at 11:10, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Thu, 16 Mar 2017 15:32:46 +0000 > Emil Velikov <emil.l.veli...@gmail.com> wrote: > >> On 16 March 2017 at 12:40, Pekka Paalanen <ppaala...@gmail.com> wrote: >> > On Tue, 21 Feb 2017 16:14:28 +0000 >> > Emil Velikov <emil.l.veli...@gmail.com> wrote: >> > >> >> From: Emil Velikov <emil.veli...@collabora.com> >> >> >> >> Currently both of libwayland-{client,server} export the same util >> >> (amongst other) symbols. >> >> >> >> Although not crucial this is something which should be avoided where >> >> possible. >> >> >> >> As such let's move the library to a shared one and introduce a static >> >> one for the purposes of wayland-scanner. >> >> >> >> Any old (existing) users of the new libwayland-{client,server} will be >> >> safe since the libwayland* libraries will pull the util one and the >> >> symbols will be resolved at runtime. >> >> >> >> Any programs building against the new libraries will have the dependency >> >> (both compile and link-wise) resolved automatically by the Requires >> >> field of the .pc file. >> >> >> >> Note: it's not possible to 'hide' the wl_list/wl_array API since it's >> >> been part for the ABI (implicitly pulled via the wayland headers) for a >> >> while, plus doing so will break KF5 and mpv, at least. >> >> >> >> v2: Rebase >> >> >> >> Signed-off-by: Emil Velikov <emil.veli...@collabora.com> >> >> --- >> >> Makefile.am | 18 ++++++++++++------ >> >> configure.ac | 2 ++ >> >> src/wayland-client-uninstalled.pc.in | 1 + >> >> src/wayland-client.pc.in | 1 + >> >> src/wayland-server-uninstalled.pc.in | 1 + >> >> src/wayland-server.pc.in | 1 + >> >> src/wayland-util-uninstalled.pc.in | 8 ++++++++ >> >> src/wayland-util.pc.in | 12 ++++++++++++ >> >> 8 files changed, 38 insertions(+), 6 deletions(-) >> >> create mode 100644 src/wayland-util-uninstalled.pc.in >> >> create mode 100644 src/wayland-util.pc.in >> > >> > Hi, >> > >> > since I have so much trouble making my mind on this patch, how about a >> > silly counter-proposal? >> > >> > Let's squash libwayland-server.so and libwayland-client.so into a >> > single libwayland.so. >> > >> > That would take care of the duplicate exported symbols issue not just >> > for the util functions, but also for the exported variables produced by >> > wayland-scanner. Since we have many programs (libEGL!) that necessarily >> > already link to both, there cannot be problems from linking to >> > everything always. >> > >> > We would still need to install dummy libwayland-server.so and >> > libwayland-client.so just for pulling in libwayland.so, but that's no >> > worse than Emil's proposition. >> > >> > Whether we have the existing .pc files telling to link to server/client >> > or just libwayland.so would be up for debate. I'm not suggesting to >> > merge the .pc files. >> > >> > libwayland-server.so and libwayland-client.so have exactly the same set >> > of dependencies. >> > >> > Any downsides to this approach vs. doing nothing vs. Emil's >> > libwayland-{client,server,util}.so? >> > >> The following come to mind: >> - any downsides of libwayland-util.so [that I can think of] also >> exist in the libwayland.so proposal > > The number of .so files? Yes. > >> - managing the compat server/client DSO in any build system will be a pain > > How so? Whose build system? > > User projects do not necessarily need any changes, ever. > > Wayland's build we need to set up once. > > So, again very much the same as your proposal. > Not quite - I see three ways to handle the compat server/client DSO: - symlinks Distros love these - I've seen cases where they just remove them.
- hardlinks Love again - if you're lucky enough the distro will ship the same file X times and/or the debug package will be broken. We even had people who explicitly hack them into symlinks even if they need to be hardlinks for legitimate reasons. - ld script, ALA libc.so/libpthread.so Not sure how portable those across C runtime(s). No idea how well dlopen/dlsym will work with these. - symbol forwarding It's a lot of fancy code and C runtime specific. You need reasonably new glibc and even then there were some bugs - one GLVND dev had a bug for 2+yo bug which did not get any input. Most/all of the above are doable, yet rather icky. >> - distributions and third party builders will "come up" with their >> own way to manage ^^ > > What might they want to manage there? > The sym/hardlink/other that are libwayland-server/client.so. >> I've seen it with the Mesa mega-drivers and you _really_ don't want to >> spend same/similar about of time hand-holding people. > > How is this in any way similar to anything in Mesa, particlarly the > mega-drivers? Not that I would even know what the problems there are. > Mega-drivers did the similar/same thing - multiple objects were folded into one. Namely nouveau_vieux_dri.so and i965_dri.so - became a single one. > Our two separate libs are tiny, there are no disk space or RAM savings > from trying to leave one out. One always needs both on your system, > there is no way to need only one. In many cases, one also loads both > anyway, regardless whether the program is a client or a server, due to > libEGL. > > Didn't mega-drivers use some sym- or hardlinking tricks? I didn't > imagine we'd need such, we'd just have libwayland-server.so and > libwayland-client.so like before, except all they do is depend on > libwayland.so which the runtime linker will load automatically. I > suppose they could be just linker scripts in .so files, but proper DSOs > are probably more portable. > Guess I should have asked you from the start. How exactly do you see libwayland.so relative to the client/server one - which provides what symbols, etc. - are the client/server DSOs - symlinks/other ? > If there is any similarity left, could you explain the issues you have > seen? > See my first note. > However, there is one thing I noticed that might make the squashing a > little awkward: libwayland-client.so and libwayland-server.so are > versioned in different numbers. That came to mind as well and although "safe" at the moment, using libwayland.so makes things harder/less flexible for the future. My proposal on the other hand does not ;-) > I don't really know if that's an actual > problem, since both have been declared backwards ABI-compatible for > years and the dummy .so files would still exist with their respective > versionings. > >> With all due respect the whole thing has become a massive bikeshed, >> admittedly with some 'help' of my end as well. >> The more we continue the less inclined I'm at fixing other issues in Wayland >> ... > > Sorry about that. > >> As a closing thought - I would really appreciate a list of concrete >> issues or "actions" where I could work against. >> Pretty please ? > > I have none. I do not have enough knowledge to form an opinion or make > a decision to accept/reject. If I can't give an authoritative Acked-by, > and no-one of the well-known expert developers did either, then I > cannot merge a change that definitely (IMO) needs seconding. > > Basically I have been waiting for someone besides you who would also > know about this topic to give their opinion on the proposal(s), because > I am disqualified. I was hoping my replies would have raised more > interest by showing I take the suggestion seriously rather than just > ignore it to death, but it didn't happen. > Hypothetical case: I'm well established Wayland developer with experience in dealing with shared libraries, other. The libwayland-util proposal comes around, I skim through the suggestion and replies. [The less hypothetical part] I likely won't bother with as the, seemingly: - "I don't know about this stuff, but I don't like it" connotation - negative input, yet lack of concrete issues/tasks to address - huge volume and orthogonal discussions (yes I'm quite guilty here as well) > Btw. the squashing started as a half-joke, since we seemed to be going > nowhere, to try and provoke more participation or points of view, but > the more I thought about squashing, the more sense it started to make. > And it's a second failed attempt to draw more attention to this > question. I got the idea for squashing from systemd libraries, not Mesa. > > Indeed, that's what I need: Reviewed-by's and Acked-by's from people > with proper reputation. > > Just like for any patch really, the strength of reviews needs to > reflect the impact of the patch. > How about we do something like Daniel ? - he pointed out some possible flaws - I dismissed those and provided a simple test case to justify my claim If every 'issue' is refuted, shout for X weeks slap an Ack and let us carry on with out lives ? Thanks Emil _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel