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

[Emil Velikov]

On 4 April 2017 at 11:26, Pekka Paalanen  wrote:
> On Tue, 4 Apr 2017 11:11:32 +0100
> Emil Velikov  wrote:
>
>> On 4 April 2017 at 09:08, Pekka Paalanen  wrote:
>> > On Mon, 3 Apr 2017 19:31:50 +0100
>> > Emil Velikov  wrote:
>> >
>> >> On 21 March 2017 at 10:05, Pekka Paalanen  wrote:
>> >> > On Mon, 20 Mar 2017 18:21:53 +
>> >> > Emil Velikov  wrote:
>> >> >
>> >> >> On 17 March 2017 at 13:32, Pekka Paalanen  wrote:
>> >
>> >> Summarising the points below. Highlighting the key words - hope it
>> >> provides some clarity.
>> >>
>> >> If we don't bump the version-info:
>> This line should not be here.
>>
>> >> A) w/o NEEDED, aka Requires.private: libwayland-util
>> >>  - Existing binaries _will_ work, as the symbols will be _implicitly_
>> >> resolved at _runtime_.
>> >>  - Newly build binaries _may_ (depending on a few factors) fail at _link_ 
>> >> time
>> >
>> > Hi,
>> >
>> > the latter item in case A is what I do not understand. To me it seemed
>> > like you were claiming that it does work, now you say it might not. Can
>> > you explain, please? (*)
>> >
>> The key is word here is "runtime" vs "link time".
>> For A runtime will be fine, while link may not work.
>
> How are link time and runtime different in symbol resolution?
>

* Runtime - the symbol may be resolved ahead of time by the
binary/project itself or via third party library.

For example using libweston, on a unpatched Mesa. Say libweston
links/dlopens libGL or uses EGL API (or uses a weston module which
does the same) and then uses the GBM API.
In a similar way one could even resolve the GLAPI symbols prior to
using libweston.

* Linking - the linker has option to preserve or discard unused
libraries. Option is controlled at _linker_ build time and overridden
via linker flags when building $project.

I.e. the following is _allowed_ to fail with unresolved symbols, with
the latter being the correct solution.

$ gcc -lm -o foo program-that-uses-log2-library.c // the linker can
discard -lm since no objects [prior to it on the command line]
reference any of its exports
$ gcc program-that-uses-log2-library.c -lm -o foo // the -o does not
matter here, I've moved it to improve clarity


-Emil
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

On Tue, 4 Apr 2017 11:11:32 +0100
Emil Velikov  wrote:

> On 4 April 2017 at 09:08, Pekka Paalanen  wrote:
> > On Mon, 3 Apr 2017 19:31:50 +0100
> > Emil Velikov  wrote:
> >  
> >> On 21 March 2017 at 10:05, Pekka Paalanen  wrote:  
> >> > On Mon, 20 Mar 2017 18:21:53 +
> >> > Emil Velikov  wrote:
> >> >  
> >> >> On 17 March 2017 at 13:32, Pekka Paalanen  wrote:  
> >  
> >> Summarising the points below. Highlighting the key words - hope it
> >> provides some clarity.
> >>
> >> If we don't bump the version-info:  
> This line should not be here.
> 
> >> A) w/o NEEDED, aka Requires.private: libwayland-util
> >>  - Existing binaries _will_ work, as the symbols will be _implicitly_
> >> resolved at _runtime_.
> >>  - Newly build binaries _may_ (depending on a few factors) fail at _link_ 
> >> time  
> >
> > Hi,
> >
> > the latter item in case A is what I do not understand. To me it seemed
> > like you were claiming that it does work, now you say it might not. Can
> > you explain, please? (*)
> >  
> The key is word here is "runtime" vs "link time".
> For A runtime will be fine, while link may not work.

How are link time and runtime different in symbol resolution?


Thanks,
pq


pgpIT0SX2I0Ww.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Emil Velikov]

On 4 April 2017 at 09:08, Pekka Paalanen  wrote:
> On Mon, 3 Apr 2017 19:31:50 +0100
> Emil Velikov  wrote:
>
>> On 21 March 2017 at 10:05, Pekka Paalanen  wrote:
>> > On Mon, 20 Mar 2017 18:21:53 +
>> > Emil Velikov  wrote:
>> >
>> >> On 17 March 2017 at 13:32, Pekka Paalanen  wrote:
>
>> Summarising the points below. Highlighting the key words - hope it
>> provides some clarity.
>>
>> If we don't bump the version-info:
This line should not be here.

>> A) w/o NEEDED, aka Requires.private: libwayland-util
>>  - Existing binaries _will_ work, as the symbols will be _implicitly_
>> resolved at _runtime_.
>>  - Newly build binaries _may_ (depending on a few factors) fail at _link_ 
>> time
>
> Hi,
>
> the latter item in case A is what I do not understand. To me it seemed
> like you were claiming that it does work, now you say it might not. Can
> you explain, please? (*)
>
The key is word here is "runtime" vs "link time".
For A runtime will be fine, while link may not work.


>> >> > Then there is the case of dlopen()'ing these libraries. I think there
>> >> > might be something unexpected to expect because we have this:
>> >> > https://cgit.freedesktop.org/wayland/weston/tree/libweston/compositor-drm.c?id=2.0.0#n1575
>> >> > introduced in commit 97f2952b.
>
>> > The scenario is this:
>> >
>> > Someone writes a plugin (dlopen()'d DSO) for his program (an
>> > executable, or maybe loaded via library). The plugin uses
>> > libwayland-client (pkg-config name) and it uses wl_list API. His
>> > program and the plugin are built with the old libwayland. Then the
>> > Wayland libs get updated to a version including your patch. Now we have
>> > a situation where the program and the plugin do *not* explicitly link
>> > to libwayland-util, yet the plugin uses symbols exported only by
>> > libwayland-util. The plugin is dlopened(). Is this not exactly the same
>> > case as why we have the hack for Mesa in Weston?
>> >
>> FWIW the Mesa design decision was made way before I started any Mesa
>> development.
>> The case you're thinking of is very close yet subtly different from
>> the one we have around Mesa.
>>
>> Here, when the plugin is linked against old wayland, it will have a
>> link against libwayland-client, libwayland-server or both.
>> Regardless of the API it uses.
>>
>> As we plugin is dlopened, the libwayland-client/server dependency will
>> a) resolve the symbol dependency for older wayland or b) pull
>> libwayland-util which will provide the required symbols, in case of
>> newer wayland.
>
> This one place where you seem to say it will work, yet above (*) you
> said it does not always work.
>
We dlopen at runtime, issue described in A is a link-time one.

>> >> > ISTR libSDL dlopen()'s libwayland-client.so which is a slightly
>> >> > different case again.
>> >> >
>> >> Yes, dlopen/dlsym is safe, regardless of who is doing it.
>> >> To explain why/who - as one does dlsym(libwayland-client.so.0_handle,
>> >> "wl_list_goo") the linker will propagate to the direct dependencies
>> >> and if any of those provide the symbol a pointer to it will be
>> >> returned.
>> >
>> > Yes, I hope it works that way too. So what went wrong in Mesa in the
>> > case I referred to?
>> >
>> In Mesa the symbols are not resolved neither directly nor indirectly.
>> Here they are handled directly (old wayland) or indirectly (new
>> wayland).
>
> What does that mean? If in Mesa "[they] are not resolved neither
> directly nor indirectly", then what does it do? What else is there? Is
> this a reference to eglGetProcAddress? If it is, then how did manually
> loading libglapi.so.0 help with it? I'm going to regret asking, aren't
> I? :-)
>
EGL has nothing to do with it.

In order to understand what/why things behave as-is, one needs the
following information.

Both loaders (GBM, EGL, GLX) and drivers (foo_dri) access* to the
GLAPI, since the GLAPI state is shared across APIs and per-thread.
Of which:
 - the drivers use GLAPI but do not link - NEED FIXING
 - GLX uses GLAPI directly and links - SAFE
 - EGL uses dlopen/dlsym to fetch required symbols - SAFE
 - *GBM does not use GLAPI, yet it dlopen the drivers - WORKAROUND in
place since Mesa 10.5.x, for problems you/others have observed.

The above diverse solutions are due to historical and implementation $reasons.

Many early day EGL/GBM users linked or dlopened GLX (libGL.so) latter
of which gets you the GLAPI symbols. Thus using GBM was fine.
As people started shifting away from GLX, the symbols were no longer
provided and people noticed the bug.
For those that use EGL _API_ before the GBM one they won't notice the
bug since libEGL will implicitly resolve the GLAPI symbols, props to
its dlopen(RTLD_GLOBAL)

Hope that provides more clarity, on the whole lovely situation.

Thanks
Emil
___
wayland-devel mailing list

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

[Pekka Paalanen]

On Mon, 3 Apr 2017 19:31:50 +0100
Emil Velikov  wrote:

> On 21 March 2017 at 10:05, Pekka Paalanen  wrote:
> > On Mon, 20 Mar 2017 18:21:53 +
> > Emil Velikov  wrote:
> >  
> >> On 17 March 2017 at 13:32, Pekka Paalanen  wrote:  

> Summarising the points below. Highlighting the key words - hope it
> provides some clarity.
> 
> If we don't bump the version-info:
> A) w/o NEEDED, aka Requires.private: libwayland-util
>  - Existing binaries _will_ work, as the symbols will be _implicitly_
> resolved at _runtime_.
>  - Newly build binaries _may_ (depending on a few factors) fail at _link_ time

Hi,

the latter item in case A is what I do not understand. To me it seemed
like you were claiming that it does work, now you say it might not. Can
you explain, please? (*)

> 
> B) with NEEDED, aka Requires: libwayland-util
>  - Existing binaries will work, if we don't bump version-info
>  - Newly build/linked binaries will fail to run with older wayland -
> regardless of version-info.
> 
> If version-info is bumped, one should use 4:0:0 for wayland-client and
> 2:0:0 for wayland-server, to reflect the backward incompatible change.
> 
> TL;DR; It can be forward or backward compatible, but not both.
> Note that even GLIBC does not guarantee compatibility in both directions.

Right, personally I have not considered the case of building against
new, running against old library binaries to be worthwhile supporting,
but if I understood Daniel's comments he was concerned about that.

Ok, I suppose these are the reasons you propose option B.

> >> > Then there is the case of dlopen()'ing these libraries. I think there
> >> > might be something unexpected to expect because we have this:
> >> > https://cgit.freedesktop.org/wayland/weston/tree/libweston/compositor-drm.c?id=2.0.0#n1575
> >> > introduced in commit 97f2952b.

> > The scenario is this:
> >
> > Someone writes a plugin (dlopen()'d DSO) for his program (an
> > executable, or maybe loaded via library). The plugin uses
> > libwayland-client (pkg-config name) and it uses wl_list API. His
> > program and the plugin are built with the old libwayland. Then the
> > Wayland libs get updated to a version including your patch. Now we have
> > a situation where the program and the plugin do *not* explicitly link
> > to libwayland-util, yet the plugin uses symbols exported only by
> > libwayland-util. The plugin is dlopened(). Is this not exactly the same
> > case as why we have the hack for Mesa in Weston?
> >  
> FWIW the Mesa design decision was made way before I started any Mesa
> development.
> The case you're thinking of is very close yet subtly different from
> the one we have around Mesa.
> 
> Here, when the plugin is linked against old wayland, it will have a
> link against libwayland-client, libwayland-server or both.
> Regardless of the API it uses.
> 
> As we plugin is dlopened, the libwayland-client/server dependency will
> a) resolve the symbol dependency for older wayland or b) pull
> libwayland-util which will provide the required symbols, in case of
> newer wayland.

This one place where you seem to say it will work, yet above (*) you
said it does not always work.

> >> > ISTR libSDL dlopen()'s libwayland-client.so which is a slightly
> >> > different case again.
> >> >  
> >> Yes, dlopen/dlsym is safe, regardless of who is doing it.
> >> To explain why/who - as one does dlsym(libwayland-client.so.0_handle,
> >> "wl_list_goo") the linker will propagate to the direct dependencies
> >> and if any of those provide the symbol a pointer to it will be
> >> returned.  
> >
> > Yes, I hope it works that way too. So what went wrong in Mesa in the
> > case I referred to?
> >  
> In Mesa the symbols are not resolved neither directly nor indirectly.
> Here they are handled directly (old wayland) or indirectly (new
> wayland).

What does that mean? If in Mesa "[they] are not resolved neither
directly nor indirectly", then what does it do? What else is there? Is
this a reference to eglGetProcAddress? If it is, then how did manually
loading libglapi.so.0 help with it? I'm going to regret asking, aren't
I? :-)

> At the same time it's somewhat frustrating, when you've spent days
> debugging similar issues in the past. Yet people state that it won't
> be a problem :-\

I just didn't understand how these can become a problem in this
specific case. I still don't.


Thanks,
pq


pgp6cRhi2ubqv.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Emil Velikov]

On 21 March 2017 at 10:05, Pekka Paalanen  wrote:
> On Mon, 20 Mar 2017 18:21:53 +
> Emil Velikov  wrote:
>
>> On 17 March 2017 at 13:32, Pekka Paalanen  wrote:
>> > On Fri, 17 Mar 2017 12:07:45 +
>> > Emil Velikov  wrote:
>> >
>> >> On 17 March 2017 at 11:10, Pekka Paalanen  wrote:
>> >> > On Thu, 16 Mar 2017 15:32:46 +
>> >> > Emil Velikov  wrote:
>> >> >
>> >> >> On 16 March 2017 at 12:40, Pekka Paalanen  wrote:
>> >
>> >> >> > 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?
>> >
>> >> 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 ?
>> >
>> > This is how I imagined it:
>> >
>> > - libwayland.so contains all the code, and exports both server and
>> >   client symbols.
>> >
>> > - libwayland-server.so and libwayland-client.so are normal DSOs that
>> >   export essentially no symbols, they only depend on libwayland.so and
>> >   cause it to be loaded.
>> >
>> > In other words, you proposed to move util functions into a third
>> > library. I proposed to move everything into a third library.
>> >
>> I'm yet to see/hear of such a DSO, and I'd imagine it will be rather
>> confusing/misleading.
>>
>> >
>> > One thing now coming to my mind is this. With your
>> > https://github.com/evelikov/wl_link_test experiments, did you try the
>> > following?
>> > 1. build and install old wayland
>> > 2. build link test
>> > 3. build and install your patched wayland
>> > 4. run link test (do not rebuild)
>> >
>> > The point here is that the application executable nor library does not
>> > have libwayland-util.so as NEEDED themselves. Still, they need to
>> > continue working fine.
>> >
>> Dan pointed out the same concert - bumping the -version-info will handle 
>> that.
>
> No, that was a different case. Daniel was worried about downgrading
> libwayland*.so, I am asking about updating libwayland*.so without
> rebuilding users.
>
> How would bumping -version-info handle it?
>
> One updates libwayland*.so, gets a new version-info, while old programs
> were expecting the old ones. I can see only two possible outcomes:
> a) either version-info guarantees that the old programs no longer start
> as the library of that version is not found, or
> b) the version-info is still compatible, so nothing changes by bumping
> it.
>
> Regardless of that, the original question remains: the user binary (e.g.
> wl_link_test) will not have libwayland-util.so as NEEDED - does it
> still work?
>
> I've been running with the assumption that it still does work, and your
> commit message seemed to imply that too, hence I started wondering why
> you want to add libwayland-util.so as NEEDED in newly built binaries?
>
> Is it necessary, which would mean that all programs would need to be
> rebuilt, or is it not necessary, in which case it would only serve to
> break newly built programs in the case Daniel pointed out?
>
Summarising the points below. Highlighting the key words - hope it
provides some clarity.

If we don't bump the version-info:
A) w/o NEEDED, aka Requires.private: libwayland-util
 - Existing binaries _will_ work, as the symbols will be _implicitly_
resolved at _runtime_.
 - Newly build binaries _may_ (depending on a few factors) fail at _link_ time

B) with NEEDED, aka Requires: libwayland-util
 - Existing binaries will work, if we don't bump version-info
 - Newly build/linked binaries will fail to run with older wayland -
regardless of version-info.

If version-info is bumped, one 

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

[Pekka Paalanen]

On Mon, 20 Mar 2017 18:21:53 +
Emil Velikov  wrote:

> On 17 March 2017 at 13:32, Pekka Paalanen  wrote:
> > On Fri, 17 Mar 2017 12:07:45 +
> > Emil Velikov  wrote:
> >  
> >> On 17 March 2017 at 11:10, Pekka Paalanen  wrote:  
> >> > On Thu, 16 Mar 2017 15:32:46 +
> >> > Emil Velikov  wrote:
> >> >  
> >> >> On 16 March 2017 at 12:40, Pekka Paalanen  wrote:  
> >  
> >> >> > 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?  
> >  
> >> 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 ?  
> >
> > This is how I imagined it:
> >
> > - libwayland.so contains all the code, and exports both server and
> >   client symbols.
> >
> > - libwayland-server.so and libwayland-client.so are normal DSOs that
> >   export essentially no symbols, they only depend on libwayland.so and
> >   cause it to be loaded.
> >
> > In other words, you proposed to move util functions into a third
> > library. I proposed to move everything into a third library.
> >  
> I'm yet to see/hear of such a DSO, and I'd imagine it will be rather
> confusing/misleading.
> 
> >
> > One thing now coming to my mind is this. With your
> > https://github.com/evelikov/wl_link_test experiments, did you try the
> > following?
> > 1. build and install old wayland
> > 2. build link test
> > 3. build and install your patched wayland
> > 4. run link test (do not rebuild)
> >
> > The point here is that the application executable nor library does not
> > have libwayland-util.so as NEEDED themselves. Still, they need to
> > continue working fine.
> >  
> Dan pointed out the same concert - bumping the -version-info will handle that.

No, that was a different case. Daniel was worried about downgrading
libwayland*.so, I am asking about updating libwayland*.so without
rebuilding users.

How would bumping -version-info handle it?

One updates libwayland*.so, gets a new version-info, while old programs
were expecting the old ones. I can see only two possible outcomes:
a) either version-info guarantees that the old programs no longer start
as the library of that version is not found, or
b) the version-info is still compatible, so nothing changes by bumping
it.

Regardless of that, the original question remains: the user binary (e.g.
wl_link_test) will not have libwayland-util.so as NEEDED - does it
still work?

I've been running with the assumption that it still does work, and your
commit message seemed to imply that too, hence I started wondering why
you want to add libwayland-util.so as NEEDED in newly built binaries?

Is it necessary, which would mean that all programs would need to be
rebuilt, or is it not necessary, in which case it would only serve to
break newly built programs in the case Daniel pointed out?

> > Then there is the case of dlopen()'ing these libraries. I think there
> > might be something unexpected to expect because we have this:
> > https://cgit.freedesktop.org/wayland/weston/tree/libweston/compositor-drm.c?id=2.0.0#n1575
> > introduced in commit 97f2952b.
> >  
> This one works perfectly fine with or w/o a version-info change - try
> the wl-dl-test.
> 
> > Does that mean that if someone writes a plugin for his app, and that
> > plugin uses wl_list, your patch would require them to at least rebuild
> > the plugin?
> >  
> There's no requirement to rebuild anything. If we're concerned about
> using FOO build against wayland X+1, while running on wayland X -
> version-info will make that an explicit error, as it should be.
> Similar thing has been done 

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

[Pekka Paalanen]

On Mon, 20 Mar 2017 17:55:25 +
Emil Velikov  wrote:

> On 17 March 2017 at 13:24, Daniel Stone  wrote:
> > Hi,
> >

> > 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 do not recall ever bumping into such, except for making
wl_interface_equal() work which needs to handle "same interface,
different address" even if we had no collisions anywhere with exported
symbols (there can be "collisions" with private or local symbols being
passed as function arguments).


Thanks,
pq


pgpaYzEG0n_AT.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Emil Velikov]

On 17 March 2017 at 13:24, Daniel Stone  wrote:
> Hi,
>
> On 17 March 2017 at 12:07, Emil Velikov  wrote:
>> On 17 March 2017 at 11:10, Pekka Paalanen  wrote:
>>> On Thu, 16 Mar 2017 15:32:46 +
>>> Emil Velikov  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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

On Fri, 17 Mar 2017 12:07:45 +
Emil Velikov  wrote:

> On 17 March 2017 at 11:10, Pekka Paalanen  wrote:
> > On Thu, 16 Mar 2017 15:32:46 +
> > Emil Velikov  wrote:
> >  
> >> On 16 March 2017 at 12:40, Pekka Paalanen  wrote:  

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

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

This is how I imagined it:

- libwayland.so contains all the code, and exports both server and
  client symbols.

- libwayland-server.so and libwayland-client.so are normal DSOs that
  export essentially no symbols, they only depend on libwayland.so and
  cause it to be loaded.

In other words, you proposed to move util functions into a third
library. I proposed to move everything into a third library.


One thing now coming to my mind is this. With your
https://github.com/evelikov/wl_link_test experiments, did you try the
following?
1. build and install old wayland
2. build link test
3. build and install your patched wayland
4. run link test (do not rebuild)

The point here is that the application executable nor library does not
have libwayland-util.so as NEEDED themselves. Still, they need to
continue working fine.

Then there is the case of dlopen()'ing these libraries. I think there
might be something unexpected to expect because we have this:
https://cgit.freedesktop.org/wayland/weston/tree/libweston/compositor-drm.c?id=2.0.0#n1575
introduced in commit 97f2952b.

Does that mean that if someone writes a plugin for his app, and that
plugin uses wl_list, your patch would require them to at least rebuild
the plugin?

ISTR libSDL dlopen()'s libwayland-client.so which is a slightly
different case again.

The case where one does rebuild the application is what you at least
tested, as I understand.

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

I do not see Daniel's Reviewed-by's or Acked-by's on this revision of
this patch, nor the earlier one.

I will not give my R-b or A-b for this patch, because I don't feel
qualified. The same goes for my counter-proposal, too. The
counter-proposal would need your R-b and someone else's A-b as well.


Thanks,
pq


pgpUy1Bc2hCzY.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Daniel Stone]

Hi,

On 17 March 2017 at 12:07, Emil Velikov  wrote:
> On 17 March 2017 at 11:10, Pekka Paalanen  wrote:
>> On Thu, 16 Mar 2017 15:32:46 +
>> Emil Velikov  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.

I tested by removing wayland-server from the pkg-config requirements
(quite tedious at 17 seconds per autogen run), and having the tests
only link to wayland-client. Failure:
/home/daniels/tmp/wl_link_test/lib.c:12: undefined reference to `wl_list_init'
/home/daniels/tmp/wl_link_test/lib.c:18: undefined reference to `wl_array_init'

I did check that the libwayland-client being used had a dependency on
libwayland-util, but the linker discarded libwayland-client as none of
its symbols were referenced.

If we had good reason to split libwayland-util out - observed
real-world breakage, a desire to grow the wayland-util exported symbol
set - then we could weigh up the least bad way and go for that. But
AFAICT, it causes us no active problems right now, apart from needing
to perhaps be careful when we change the inner workings when people
are determined to have mismatched libwayland-client vs.
libwayland-server versions. Fine, but given the entire implementation
of all those functions is essentially ABI anyway, that's something we
can live with. I hope you understand that I think breaking actual real
users for a hypothetical benefit is not worth it.

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

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

[Emil Velikov]

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

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

[Pekka Paalanen]

On Thu, 16 Mar 2017 15:32:46 +
Emil Velikov  wrote:

> On 16 March 2017 at 12:40, Pekka Paalanen  wrote:
> > On Tue, 21 Feb 2017 16:14:28 +
> > Emil Velikov  wrote:
> >  
> >> From: Emil Velikov 
> >>
> >> 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 
> >> ---
> >>  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.

>  - distributions and third party builders will "come up" with their
> own way to manage ^^

What might they want to manage there?

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

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.

If there is any similarity left, could you explain the issues you have
seen?

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

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

[Emil Velikov]

On 16 March 2017 at 12:40, Pekka Paalanen  wrote:
> On Tue, 21 Feb 2017 16:14:28 +
> Emil Velikov  wrote:
>
>> From: Emil Velikov 
>>
>> 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 
>> ---
>>  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 ?

Thanks
Emil
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

On Tue, 21 Feb 2017 16:14:28 +
Emil Velikov  wrote:

> From: Emil Velikov 
> 
> 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 
> ---
>  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?


Thanks,
pq


pgp_bLhzOlTb8.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Emil Velikov]

From: Emil Velikov 

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

diff --git a/Makefile.am b/Makefile.am
index 7e15465..ad3fdf0 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -25,7 +25,7 @@ pkgconfig_DATA =
 bin_PROGRAMS = wayland-scanner
 wayland_scanner_SOURCES = src/scanner.c
 wayland_scanner_CFLAGS = $(EXPAT_CFLAGS) $(LIBXML_CFLAGS) $(AM_CFLAGS)
-wayland_scanner_LDADD = $(EXPAT_LIBS) $(LIBXML_LIBS) libwayland-util.la
+wayland_scanner_LDADD = $(EXPAT_LIBS) $(LIBXML_LIBS) libwayland-util-static.la
 pkgconfig_DATA += src/wayland-scanner.pc
 
 if DTD_VALIDATION
@@ -40,16 +40,17 @@ $(BUILT_SOURCES) : wayland-scanner
 wayland_scanner = $(top_builddir)/wayland-scanner
 endif
 
-libwayland_util_la_CFLAGS = $(AM_CFLAGS)
-libwayland_util_la_SOURCES =   \
+noinst_LTLIBRARIES = libwayland-util-static.la
+
+libwayland_util_static_la_CFLAGS = $(AM_CFLAGS)
+libwayland_util_static_la_SOURCES =\
src/wayland-util.c  \
src/wayland-util.h
 
-noinst_LTLIBRARIES = libwayland-util.la
 
 if ENABLE_LIBRARIES
 noinst_LTLIBRARIES += libwayland-private.la
-lib_LTLIBRARIES = libwayland-server.la libwayland-client.la
+lib_LTLIBRARIES = libwayland-util.la libwayland-server.la libwayland-client.la
 
 libwayland_private_la_CFLAGS = $(FFI_CFLAGS) $(AM_CFLAGS)
 libwayland_private_la_SOURCES =\
@@ -73,6 +74,11 @@ nodist_include_HEADERS = \
protocol/wayland-server-protocol.h  \
protocol/wayland-client-protocol.h
 
+libwayland_util_la_CFLAGS = $(AM_CFLAGS)
+libwayland_util_la_SOURCES =   \
+   src/wayland-util.c  \
+   src/wayland-util.h
+
 libwayland_server_la_CFLAGS = $(FFI_CFLAGS) $(AM_CFLAGS) -pthread
 libwayland_server_la_LIBADD = $(FFI_LIBS) libwayland-private.la 
libwayland-util.la -lrt -lm
 libwayland_server_la_LDFLAGS = -version-info 1:0:1
@@ -95,7 +101,7 @@ nodist_libwayland_client_la_SOURCES =\
protocol/wayland-client-protocol.h  \
protocol/wayland-protocol.c
 
-pkgconfig_DATA += src/wayland-client.pc src/wayland-server.pc
+pkgconfig_DATA += src/wayland-util.pc src/wayland-client.pc 
src/wayland-server.pc
 
 protocol/%-protocol.c : $(top_srcdir)/protocol/%.xml
$(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) code < $< > $@
diff --git a/configure.ac b/configure.ac
index c50027b..95ccea0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -196,8 +196,10 @@ AC_CONFIG_FILES([Makefile
 src/wayland-server-uninstalled.pc
 src/wayland-client-uninstalled.pc
 src/wayland-scanner-uninstalled.pc
+src/wayland-util-uninstalled.pc
 src/wayland-server.pc
 src/wayland-client.pc
 src/wayland-scanner.pc
+src/wayland-util.pc
 src/wayland-version.h])
 AC_OUTPUT
diff --git a/src/wayland-client-uninstalled.pc.in 
b/src/wayland-client-uninstalled.pc.in
index 732736e..c12a917 100644
--- a/src/wayland-client-uninstalled.pc.in
+++ b/src/wayland-client-uninstalled.pc.in
@@ -5,5 +5,6 @@ protocoldir=@abs_top_builddir@/protocol
 Name: Wayland Client
 Description: Wayland client side library (not installed)
 Version: @PACKAGE_VERSION@
+Requires.private: wayland-util
 Cflags: -I${includedir} -I${protocoldir}
 Libs: -L${libdir} -lwayland-client
diff --git a/src/wayland-client.pc.in b/src/wayland-client.pc.in
index eef61da..d76f83d 100644
--- a/src/wayland-client.pc.in
+++ b/src/wayland-client.pc.in
@@ -8,5