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

[Emil Velikov]

On 4 April 2017 at 11:26, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Tue, 4 Apr 2017 11:11:32 +0100
> Emil Velikov <emil.l.velikov at gmail.com> wrote:
>
>> On 4 April 2017 at 09:08, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> > On Mon, 3 Apr 2017 19:31:50 +0100
>> > Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> >
>> >> On 21 March 2017 at 10:05, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> >> > On Mon, 20 Mar 2017 18:21:53 +0000
>> >> > Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> >> >
>> >> >> On 17 March 2017 at 13:32, Pekka Paalanen <ppaalanen at gmail.com> 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