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

[Pekka Paalanen]

On Mon, 4 Jul 2016 16:17:08 +0100
Emil Velikov <emil.l.velikov at gmail.com> wrote:

> 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
> (/usr/lib/weston/desktop-shell.so)
> undefined symbol: zwp_input_panel_surface_v1_interface
> (/usr/lib/weston/desktop-shell.so)
> undefined symbol: weston_stable_fade_run
> (/usr/lib/weston/desktop-shell.so)
> undefined symbol: weston_compositor_schedule_repaint
> (/usr/lib/weston/desktop-shell.so)
> undefined symbol: weston_surface_set_size
> (/usr/lib/weston/desktop-shell.so)
> undefined symbol: weston_move_scale_run (/usr/lib/weston/desktop-shell.so)
> undefined symbol: weston_matrix_multiply
> (/usr/lib/weston/desktop-shell.so)
> undefined symbol: weston_install_debug_key_binding
> (/usr/lib/weston/desktop-shell.so)
> 
> > 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(?).

Hi Emil,

depends on your definition of broken. We have been compiling and
running the test suite just fine all the time, both before and after
the patch that added libweston.so.

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

Generated ones are a good question. I wonder if we should fix every
module to include the generated .c file. It seems a bit messy to rely
on those being exported by libweston.

Having multiple copies of the generated .c code should not cause any
issues, just take a bit more space.

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

I would think that anything that gets resolved by linking to libweston
is good. The same for any external libs.

The remaining things would probably have to be split between libweston
modules and weston modules. Libweston modules may not require any
symbols from weston the executable, but weston modules might.

So I believe at least all libweston modules we install need to be able
to link with no-undefined and not depend on weston the executable. I
believe that should be already the case, the only thing remaining is to
actually link them against libweston.

Test and weston modules are another matter and need case by case
handling. In most cases they should be fine with libweston alone, but I
think it's possible some might depend on weston the executable exported
symbols. In that case they cannot be built with no-undefined by design.

Unfortunately I ran out of time before I could review any further.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160705/9a14d034/attachment.sig>