[PATCH weston 0/6] Rework libweston versioning, take 2(?)

Emil Velikov emil.l.velikov at gmail.com
Mon Jul 4 15:17:08 UTC 2016

On 4 July 2016 at 15:55, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Mon,  4 Jul 2016 15:23:48 +0100
> Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> Hi all,
>> Here is a respin of the earlier series which changes how libweston is
>> named, and thus shipped. I believe all the logic/reasoning is explicitly
>> stated, although if something feels amiss, please let me know.
>> NOTE: WARNING: The series exposes a fatal bug in weston thus the tests
>> fail to build (let alone run).
>> Namely: atm some/many of the modules are built with unresolved symbols.
>> Is that a bug or by design ? From a quick look it seems to be the
>> latter.
> Hi Emil,
> what unresolved symbols?
For the exact list check your system weston with ldd -r foo. For
example on my Arch setup with weston 1.10.0-1

$ ldd -r /usr/lib/weston/* | grep undefined | wc -l

$ ldd -r /usr/lib/weston/* | grep undefined | head
undefined symbol: weston_log    (/usr/lib/weston/cms-colord.so)
undefined symbol: weston_log    (/usr/lib/weston/cms-static.so)
undefined symbol: zwp_input_panel_v1_interface
undefined symbol: zwp_input_panel_surface_v1_interface
undefined symbol: weston_stable_fade_run
undefined symbol: weston_compositor_schedule_repaint
undefined symbol: weston_surface_set_size
undefined symbol: weston_move_scale_run (/usr/lib/weston/desktop-shell.so)
undefined symbol: weston_matrix_multiply
undefined symbol: weston_install_debug_key_binding

> You mean the symbols that are resolved from Weston the executable?
I'd imagine so.

> Or maybe the symbols that libweston exports, and test modules expect to
> be present without actually linking to libweston?
> Yeah, all that needs to be fixed in time. Should we link all modules to
> libweston? I'd assume that should fix almost all of them, but I haven't
> looked yet.
> Obviously we cannot land patches that break the tests.
Agree. Sadly things were already broken before I came - my changes
only exposed the existing bugs(?).

>> If anyone is interested in resolving this please grep through mesa for
>> "no-undefined" - it handles both -no-undefined and -Wl,--no-undefined in
>> a portable manner.
> Preferably all the binaries we build would be using no-undefined. It
> was not possible before libweston because weston the executable
> provided lots of them, but now it should be achievable and a very good
> improvement in catching stupid bugs.
>From a quick look - most symbols are (should come) from libweston now
that we have it. Although there's a bunch of generated ones, which I'm
not sure about.

It'll be great if someone with more weston/wayland experience than me,
takes a look (at the output of ldd) and categorises them. Then myself
and/or others can divide and concur.


More information about the wayland-devel mailing list