<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 16, 2015 at 11:10 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, 16 Oct 2015 10:27:56 +0200<br>
Hardening <<a href="mailto:rdp.effort@gmail.com">rdp.effort@gmail.com</a>> wrote:<br>
<br>
> Le 16/10/2015 03:28, Bryce Harrington a écrit :<br>
> > On Tue, Oct 13, 2015 at 01:59:13PM +0200, Joaquim Duran wrote:<br>
> >> Hello,<br>
> >><br>
> >> When configuring the Weston project, it is possible to disable (don't<br>
> >> include) the library libxkbcommon. To compile Weston successfully,<br>
> >> even if the option --disable-xkbcommon is specified, the library must<br>
> >> be installed because the file src/compositor.h requires it.<br>
> ><br>
> > Joaquim, good find.<br>
> ><br>
> > From the comments in <a href="http://configure.ac" rel="noreferrer" target="_blank">configure.ac</a>:<br>
> ><br>
> >           AS_HELP_STRING([--disable-xkbcommon], [Disable libxkbcommon<br>
> >                   support: This is only useful in environments<br>
> >                   where you do not have a hardware keyboard. If<br>
> >                   libxkbcommon support is disabled clients will not<br>
> >                   be sent a keymap and and must know how to<br>
> >                   interpret the keycode sent for any key event.]),,<br>
> ><br>
> > So it sounds like this is a special case that is intended to work.<br>
> ><br>
> > The header include was from commit 855028fe three years ago, while the<br>
> > --disable-xkbcommon was added by 382ff46f just two years ago.  That<br>
> > makes me think that your situation was simply overlooked.<br>
> ><br>
> > If that's true, then presumably the fix would involve peppering<br>
> > compositor.* and other files with tests like,<br>
> ><br>
> > #ifdef ENABLE_XKBCOMMON<br>
> > ...<br>
> > #endif<br>
> ><br>
> > For example it looks like the weston_xkb_info struct would need to<br>
> > either be removed or stubbed out, and users of it be disabled.  There<br>
> > are also some weston calls that use xkb_keymap, xkb_rule_names,<br>
> > etc. structures for params that'd need addressed.<br>
> ><br>
> > On the face of it, seems like it could be a fair amount of work, and a<br>
> > bit invasive, but maybe there's some tricks to make it simpler<br>
> > (typedeffing the unsupported struct args and so on.)<br>
> ><br>
> > Alternatively, --disable-xkbcommon could be dropped.  However I get the<br>
> > sense it actually solves a real world need, and functional regression is<br>
> > rarely a good idea.<br>
> ><br>
><br>
> I'm to fix the bug. Anyway it's almost sure that there's no real usage<br>
> of this flag as otherwise weston does not compile...<br>
<br>
</div></div>I would be suprised if it didn't work at the time it was added. I<br>
suspect we broke it later, and no-one noticed.<br>
<br>
I recall some discussions about some obscure embedded platform where<br>
xkbcommon, even when it's tiny, was deemed as waste of space,<br>
especially along with the xkeyboard-config database (even though you<br>
don't even need the whole database). Or maybe it was about wasting<br>
memory. Can't recall.<br></blockquote><div><br></div><div>If you know of a way to strip some parts of the database, I'm interested. I've tried only keep evdev mappings and a few layouts, but going at it it seemed like a very hard task so I just gave up.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hrm, now that I actually test --disable-xkbcommon, Weston *does* build.<br>
All I get during build is:<br>
<br>
  CC       src/weston-input.o<br>
/home/pq/git/weston/src/input.c: In function ‘weston_seat_init_keyboard’:<br>
/home/pq/git/weston/src/input.c:2226:1: warning: label ‘err’ defined but not used [-Wunused-label]<br>
/home/pq/git/weston/src/input.c: In function ‘weston_keyboard_reset_state’:<br>
/home/pq/git/weston/src/input.c:2238:20: warning: unused variable ‘state’ [-Wunused-variable]<br>
/home/pq/git/weston/src/input.c: At top level:<br>
/home/pq/git/weston/src/input.c:555:1: warning: ‘weston_xkb_info_destroy’ used but never defined [enabled by default]<br>
/home/pq/git/weston/src/input.c:989:1: warning: ‘run_modifier_bindings’ defined but not used [-Wunused-function]<br>
<br>
And no other warning or error.<br>
<br>
I do not get a build failure, because libxkbcommon is installed in my<br>
system, and so I don't need additional -I flags to find its headers.<br>
When we build modules (backends, plugins, anything), missing symbols<br>
are not fatal because the parent executable is providing some we must<br>
not error on.<br>
<br>
At least x11-backend.so will fail to load doe to missing<br>
xkbcommon symbols. Makes me wonder if there is some other backend that<br>
doesn't fail so.<br>
<br>
So it's possible someone is or was actually getting away with this,<br>
having xkbcommon installed for the build but not at runtime.<br>
<br>
We can remove --disable-xkbcommon, but be prepared having to revert and<br>
fix that properly later.<br>
<br>
<br>
Thanks,<br>
pq</blockquote></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Arnaud</div></div></div>
</div></div>