[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190405162109.4hv6lqpd6manzjju@treble>
Date: Fri, 5 Apr 2019 11:21:09 -0500
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: David Laight <David.Laight@...LAB.COM>
Cc: 'Luis Ressel' <aranea@...ah.de>,
Peter Zijlstra <peterz@...radead.org>,
open list <linux-kernel@...r.kernel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH] objtool: Don't use -Werror
On Fri, Apr 05, 2019 at 04:16:14PM +0000, David Laight wrote:
> From: Luis Ressel
> > Sent: 05 April 2019 17:06
> > On Fri, Apr 05, 2019 at 09:39:26AM -0500, Josh Poimboeuf wrote:
> >
> > > Hm, I would actually argue the reverse. Warnings are generally bad and
> > > -Werror is useful for ensuring that we don't have any. For warnings
> > > that don't provide value, we just disable those individual warnings.
> >
> > Sure, during development it's an excellent idea to investigate compiler
> > warnings, and -Werror can be useful for that. But the Linux kernel is
> > built by countless users in wildly varying environments, and it's almost
> > a given that someone will use a compiler that'll complain about a valid
> > part of your code whose style it considers bad.
> >
> > As an example, the warning that's breaking the build for me is -Wundef
> > complaining about several "#if UNDEFINED_IDENTIFIER" constructs in the
> > libelf headers. (I agree with gcc in considering this bad style, but
> > it's perfectly valid C, and there probably wasn't a warning about it
> > back when this header was written.)
>
> In which case you should be looking at a way of removing -Wundef
> not removing -Werror.
Agreed.
> FWIW I had to update libelf.so from version 0.153 to 0.165 in
> order for the amd64 orc unwinder code in objtool to not generate
> corrupt output files.
> That is an Ubuntu 13.04 system - nothing like 10 years old.
Ah. It would be great if we had a patch to fail the build for old
versions of elfutils-libelf as well.
--
Josh
Powered by blists - more mailing lists