From: David Laight <David.Laight@ACULAB.COM>
To: 'Luis Ressel' <aranea@aixah.de>, Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
open list <linux-kernel@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH] objtool: Don't use -Werror
Date: Fri, 5 Apr 2019 16:16:14 +0000 [thread overview]
Message-ID: <a9dfc08702044b3db89c0584c0f79229@AcuMS.aculab.com> (raw)
In-Reply-To: <20190405160550.62arkmvj67zm6oc2@vega.skynet.aixah.de>
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.
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.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2019-04-05 16:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-05 11:01 Luis Ressel
2019-04-05 12:39 ` Josh Poimboeuf
2019-04-05 14:24 ` Luis Ressel
2019-04-05 14:39 ` Josh Poimboeuf
2019-04-05 16:05 ` Luis Ressel
2019-04-05 16:15 ` Josh Poimboeuf
2019-04-05 16:30 ` Luis Ressel
2019-04-05 16:16 ` David Laight [this message]
2019-04-05 16:21 ` Josh Poimboeuf
2019-04-05 16:35 ` David Laight
2019-04-05 17:12 ` Josh Poimboeuf
2019-04-05 17:17 ` David Laight
2019-04-05 17:22 ` Josh Poimboeuf
2019-04-08 9:20 ` David Laight
2019-04-08 13:02 ` Josh Poimboeuf
2019-04-05 16:26 ` 'Luis Ressel'
2019-04-05 16:35 ` 'Luis Ressel'
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a9dfc08702044b3db89c0584c0f79229@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=aranea@aixah.de \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®