[PATCH libevdev 2/2] Reintroduce -fstack-protector
peter.hutterer at who-t.net
Sun Sep 15 23:09:21 PDT 2013
On Fri, Sep 13, 2013 at 05:15:32PM +0200, David Herrmann wrote:
> 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.
I agree with Colin's basic sentiment. There are a few useful flags that we
should definitely have (-Wall, etc.), a few we definitely shouldn't (e.g.
-g) and a few that aren't quite as obvious. since this one is giving us
grief and it can make life difficult for others I've reverted the patch,
removing -fstack-protector again. let's hope we'll never really need it :)
f5e65ea..e156f9a master -> master
More information about the Input-tools