[PATCH libevdev 2/2] Reintroduce -fstack-protector

David Herrmann dh.herrmann at gmail.com
Fri Sep 13 08:15:32 PDT 2013


Hi Colin

On Fri, Sep 13, 2013 at 5:00 PM, Colin Walters <walters at verbum.org> wrote:
> On Fri, 2013-09-13 at 11:43 +0200, Giovanni Campagna wrote:
>
>> I must say, I don't know why it would fail (libssp appears to be
>> enabled in the build configuration!) or why it would fail for libevdev
>> and not for systemd.
>> CCing Colin, who is maintaining the ostree build and probably knows more.
>                                       ^ gnome-continuous now
>
> So from what I can tell the stack protector really needs the entire
> system to be consistently compiled with it.
>
> At a high level, I think components (git repositories) should feel free
> to set up default warning flags and possibly use a targeted subset of
> -Werror=foo.  But please don't inject non-warning flags like this unless
> there is a very good reason.
>
> The right way to do -fstack-protector is to have something like
> redhat-rpm-config or other global CFLAGS system controlling *all*
> components.
>
> If for example I wanted to disable the stack protector to debug
> something, it becomes really tedious to track down which components have
> -fstack-protector in their default configure.ac.
>
> If you want it on as a developer just running "configure/make" manually,
> it's pretty easy to make your own shell script alias that does:
> env NOCONFIGURE=1 ./autogen.sh ; env CFLAGS='-fstack-protector-all -Wall
> -Werror' ./configure --prefix=...
>
> gnome-continuous is carrying patches to remove it from SPICE for this
> reason.
>
> ...
>
> Ok so I just debugged this, the reason it's failing is because tools/ is
> not using -fstack-protector.  Patch attached.

Thanks for tracking it down. I wonder why it didn't fail for anybody
else, though. More importantly, we don't do static linking or similar
in tools/, so why doesn't ld correctly link and resolve the symbols?

Anyway, it's missing your Signed-off-by line, could you provide it as
a response here? (same rules as for the kernel apply)

For everything else Peter has to decide. I have no strong opinion on it.

Thanks
David


More information about the Input-tools mailing list