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

Emil Velikov emil.l.velikov at gmail.com
Thu Mar 16 15:32:46 UTC 2017

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
 - managing the compat server/client DSO in any build system will be a pain
 - distributions and third party builders will "come up" with their
own way to manage ^^
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.

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

As a closing thought - I would really appreciate a list of concrete
issues or "actions" where I could work against.
Pretty please ?


More information about the wayland-devel mailing list