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

Fri Mar 17 12:07:45 UTC 2017

On 17 March 2017 at 11:10, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Thu, 16 Mar 2017 15:32:46 +0000
> Emil Velikov <emil.l.velikov at gmail.com> wrote:
>
>> On 16 March 2017 at 12:40, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> > On Tue, 21 Feb 2017 16:14:28 +0000
>> > Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> >
>> >> From: Emil Velikov <emil.velikov at 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.velikov at 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