On Fri, 16 Sep 2016 14:47:39 +0100
Emil Velikov <emil.l.veli...@gmail.com> wrote:

> Hi Pekka,
> Thanks again for keeping up.
> On 16 September 2016 at 10:46, Pekka Paalanen <ppaala...@gmail.com> wrote:
> > Hi,
> >
> > there seems to be two different issues discussed here.
> >  
> You cought me, yes there are.
> > 1) libwayland-client and libwayland-server export the same interface
> > symbols each, and cannot stop exporting them. You proposed to
> > consolidate them into a third library.
> >
> > I don't think that is necessary.
> >
> > 2) Push everyone to build and install a .so and generated headers for
> > every protocol extension XML file they offer for public use. You claim
> > it would have benefits over the static build approach.


> > All such libraries would be ignored by all other language bindings.
> > Language bindings have their own scanners generating wrappers suitable
> > for their language directly. The symbols we are talking about are just
> > a curiosity of the C language bindings.
> >  
> NB: other languages can reuse C binding, no ? Obviously they can use
> the native ones as well.

They can build on C bindings with great effort and pain, something which
they usually prefer to avoid, and upstream discourages. They cannot
build on the C bindings without writing a specific shim library in C or
maybe C++.

> There's more to it - you're suggesting to hide them by default (the
> non libwayland ones of course). I'm saying that one should keep them
> around (in alternative form) by default and allow people to hide them.

Right. It certainly took hours and hours of debate to get to this
sentence that finally explains what the big issue was.

> >> Similar to libwayland-util.so, any old and new projects will continue
> >> to work and the symbol duplication will be resolved.  
> >
> > You only resolve the duplication between libwayland-server and
> > libwayland-client, which has never been a problem heard about in
> > upstream. The symbols exported by them are identical, so it does not
> > matter which one provides them.
> >  
> The "don't provide duplicate symbols" rule/suggestion/etc. is there
> for a reason.
> Just because in this particular place (project) and time those have
> identical implementation there is no guarantee that things will stay
> the same.

The fundamental architecture of libwayland requires them to be
identical. This has been enshrined in the ABI.

> IIRC it carries the XML only for the client header, yet it depends on
> libEGL.so. And yes, they _expect_ to have a cannonical provider for
> the _interface symbol(s). It's only fair to assume that they're not
> the only ones (but perhaps for other _interface symbols).

EGADS, libva is even more insane than I could have ever imagined.

So, you say that we can never stop Mesa from exporting
wl_drm_interface. Too bad.

> The reluctance on the topic strikes me, bth:
>  - Nobody is expecting you/others to hack on this. Fwiw we're talking
> about ~20 loc for wayland.
>  - The proposal preserves your suggestion, yet it is not the default option.
>  - New projects will continue to work as before with zero changes and
> they can opt for either new 'route'.
>  - And last but not least, it preserves ABI compat and mitigates
> existing and future problems.

You want people who did it right to go fix their code.
I want people who did it wrong to go fix their code.

I think that pretty much sums it up. Unfortunately I cannot see any way
around it either. People who did it right will need to pay the price.
I'm starting to recall lots of precedence of that too. I have been in
denial and the world is a much darker place than I remembered.

I still do not want the proliferation of DSOs.

Wait, didn't you or someone clean up Mesa's exports in the past?


Attachment: pgpWswLf9VT53.pgp
Description: OpenPGP digital signature

wayland-devel mailing list

Reply via email to