[PATCH 1/2] [pr53679] libgo: add a --enable-werror configure flag

[Ian Lance Taylor]

On Fri, Jan 25, 2013 at 7:20 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Friday 25 January 2013 19:13:55 Ian Lance Taylor wrote:
>> On Tue, Jan 15, 2013 at 9:45 AM, Mike Frysinger wrote:
>> > On Tuesday 15 January 2013 09:56:06 Ian Lance Taylor wrote:
>> >> On Sun, Dec 23, 2012 at 3:30 PM, Mike Frysinger wrote:
>> >> > diff --git a/libgo/configure.ac b/libgo/configure.ac
>> >> > index 8cde50b..63d8cbc 100644
>> >> > --- a/libgo/configure.ac
>> >> > +++ b/libgo/configure.ac
>> >> > @@ -50,8 +50,11 @@ AC_PROG_AWK
>> >> >
>> >> >  WARN_FLAGS='-Wall -Wextra -Wwrite-strings -Wcast-qual'
>> >> >  AC_SUBST(WARN_FLAGS)
>> >> >
>> >> > -dnl FIXME: This should be controlled by --enable-maintainer-mode.
>> >> > -WERROR="-Werror"
>> >> > +AC_ARG_ENABLE(werror, [AS_HELP_STRING([--enable-werror],
>> >> > +                                      [turns on -Werror
>> >> > @<:@default=yes@:>@])]) +if test "x$enable_werror" != "xno"; then
>> >> > +  WERROR="-Werror"
>> >> > +fi
>> >> >
>> >> >  AC_SUBST(WERROR)
>> >> >
>> >> >  glibgo_toolexecdir=no
>> >>
>> >> Can you say something about when you needed this?  What errors were you
>> >> seeing?
>> >
>> > the referenced PR describes one:
>> > /build/src/gcc-4.7.1/libgo/runtime/print.c: In function 'gwrite':
>> > /build/src/gcc-4.7.1/libgo/runtime/print.c:20:3: error: ignoring return
>> > value of 'write', declared with attribute warn_unused_result
>> > [-Werror=unused-result] cc1: all warnings being treated as errors
>> >
>> > this bites distros that enable security settings by default (such as
>> > fortify and ssp).  but ignoring even that, i don't believe releases
>> > should build all the time with -Werror -- i'm fine with defaulting to on
>> > as long as there is a configure flag to turn it off which is what this
>> > does like is already handled in much of the sourceware tree.  -Werror is
>> > great for development, but sucks when deployed on actual systems.  the
>> > assumptions made at time of checkin rarely stay constant forever (in
>> > this case, a changing lib C can easily break it). -mike
>>
>> Thanks for the explanation.
>>
>> Committed to mainline.
>
> thanks!  mind if i commit it to gcc-4.6 and gcc-4.7 too ?

I certainly don't mind.  You should probably get agreement from the
release managers although this seems safe enough.

Ian