public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mjw@redhat.com>
To: elfutils-devel@lists.fedorahosted.org
Subject: Re: Getting rid of portable branch (Was: [PATCH 3/6] Fall back on utimes if futimes is not available)
Date: Thu, 14 May 2015 13:01:20 +0200	[thread overview]
Message-ID: <20150514110120.GB26243@blokker.redhat.com> (raw)
In-Reply-To: 20150513160950.GH22975@vapier

[-- Attachment #1: Type: text/plain, Size: 2194 bytes --]

Hi Mike,

On Wed, May 13, 2015 at 12:09:50PM -0400, Mike Frysinger wrote:
> On 13 May 2015 16:18, Mark Wielaard wrote:
> > On Thu, 2015-05-07 at 22:08 -0400, Mike Frysinger wrote:
> > > > If there are specific hacks you would like to see brought over from the
> > > > portable branch to master, please do propose and we can discuss them.
> > > > But I really think none of them are needed or should be used these days.
> > > 
> > > there's still the issue of --disable-werror
> > 
> > I believe we discussed before, but could you remind me why it is
> > necessary for newer GCC versions?
> > 
> > If there are any warnings that are turned into errors we should really
> > just fix them. Do you have any specific examples?
> > 
> > What does the configure option add over just using CFLAGS=-Wno-error?
> 
> because you guys (reasonably) cannot test every gcc/C library
> version/flags/arch combination.  focusing on newer versions makes sense,
> but not all distros are always running the latest.  i also agree that
> having it default to on is ok and some distros which have tight control
> over everything (like fedora) will set it to on.  but i think that should
> be left to the distro to control.  in practice, we already are either by
> `sed` or patching in the werror configure flag.

Sure, but if you are using none supported versions of gcc and glibc you
are on your own already and will have to patch yourself. For the rest we
would really be error free. I do hope to setup a buildbot soon with slaves
for most supported arches to catch any issues early.

What is the advantage of --disable-werror over using CFLAGS=-Wno-error?

> keep in mind that not all warnings are even correct -- gcc has false
> positives from time to time.  trying to track how to squelch those across
> multiple gcc versions is a waste of time.

I don't think so (for a reasonable number of gcc versions). We pick the
enabled warning flags carefully and make sure no warnings slip through
(possible disabling them per file if necessary). If we enable specific
warnings in elfutils they have often caught important bugs that really
should be fixed.

Cheers,

Mark

             reply	other threads:[~2015-05-14 11:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-14 11:01 Mark Wielaard [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-05-14 11:04 Mark Wielaard
2015-05-13 16:17 Frank Ch. Eigler
2015-05-13 16:09 Mike Frysinger
2015-05-13 14:18 Mark Wielaard
2015-05-08  2:08 Mike Frysinger
2015-05-06 11:37 Mark Wielaard
2015-05-06 11:22 Frank Ch. Eigler
2015-05-06 10:17 Mark Wielaard

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=20150514110120.GB26243@blokker.redhat.com \
    --to=mjw@redhat.com \
    --cc=elfutils-devel@lists.fedorahosted.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).