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

[Emil Velikov]

On 17 March 2017 at 13:24, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi,
>
> On 17 March 2017 at 12:07, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> 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:
>>>>  - 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.
>
> These don't work for DSOs loaded through ld.so. :\ For modules it's
> fine, since you're only asking dlopen() to open a file and use that,
> whatever it may be. But if ld.so is trying to satisfy a DT_NEEDED for
> libwayland-client.so.1, it will open libwayland-client.so.1, see that
> its SONAME is libwayland.so.1, decide it does not satisfy the
> dependency, and ignore it. Maybe not the case everywhere, but at least
> on Debian jessie on armhf, older Mali binaries which shipped
> libEGL.so.1/libGLESv2.so.2/etc as symlinks to libmali.so, I had to
> create real ELF objects for each library, with a matching SONAME and a
> DT_NEEDED to libmali.so.
>
>>  - 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.
>
> So let's take libwayland.so off the table then, and come back to
> libwayland-util.so. Thanks for putting together your testcase, which I
> did try, but it doesn't actually work.
>
> Firstly, libwayland-server in this patchset gains a hard Requires on
> wayland-util, meaning that -lwayland-util explicitly finds its way
> into link lines. So, even if you're only using old ABI, if you build a
> binary against a post-split library, you cannot run it in an
> environment with a pre-split library. This is a dealbreaker for me,
> because it is an ABI change.
>
Thanks for testing !

Very valid point -  the way to address that is to bump the
-version-info, like it has been done [twice] already.
And if one is brave/silly enough to dlopen/dlsym the symbols out of
libwayland-client/server regardless of the details (which version/etc)
things will just work. Do experiment with the wl-dl-test program in
the repo.

>
> NAK from me.
>
> There are real issues this causes, and I'm still not in any way
> convinced of the rationale for making this rather dangerous change in
> the first place. Much like with the discussion on Mesa's symbol
> exports, in a vacuum you are correct: it should have been done this
> way in the first place. If there was a compelling rationale to change
> it, then we could have a discussion about the best thing to do.
>
> Right now, you have failed to convince people that the upsides of your
> change (which are entirely hypothetical AFAICT) are outweigh the
> downsides (actually breaking real-world users who exist and would be
> seriously pissed off). My NAK is for the downside (this breakage,
> another DSO to version), and given the risk of extremely subtle
> breakage given everyone's disparate toolchain versions and
> configurations, will stand until there is a well-established set of
> benefits for doing this which outweighs that risk.
>
> If you want to avoid sinking too much time into this, I suggest you
> work on polishing the rationale first.
>
Agreed, I could and should sell it out better.

There's a thing that I've been wondering - have you/Pekka/others had
"fun" experience fixing up after symbol collisions ?
I'm been "blessed" to spend days tracking both in-kernel and
userspaces instances. It's a lot harder track since it doesn't always
behave in the same way plus it's not something one expects.

Yes, the type of issue I'm thinking is 'hypothetical', but once you've
burnt a few times you don't listen to the people saying "it will never
happen".
At the same time, any issues that may arise are also hypothetical and
I greatly welcome _everyone_ to voice their concern so that I can
address it.

-Emil