Re: pkg/49752: ./bootstrap --unpriveleged fails on Alpine Linux

[michael lowell roberts <epergne%hotmail.com@localhost>]

The following reply was made to PR pkg/49752; it has been noted by GNATS.

From: michael lowell roberts <epergne%hotmail.com@localhost>
To: gnats-bugs%NetBSD.org@localhost, pkg-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
 pkgsrc-bugs%netbsd.org@localhost
Cc: 
Subject: Re: pkg/49752: ./bootstrap --unpriveleged fails on Alpine Linux
Date: Sun, 12 Apr 2015 11:30:39 -0700

 On Wed, Mar 18, 2015, at 12:25 PM, David Holland wrote:
 > The following reply was made to PR pkg/49752; it has been noted by GNATS.
 > 
 > From: David Holland <dholland-pbugs%netbsd.org@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc: 
 > Subject: Re: pkg/49752: ./bootstrap --unpriveleged fails on Alpine Linux
 > Date: Wed, 18 Mar 2015 19:20:39 +0000
 > 
 >  On Tue, Mar 17, 2015 at 01:40:00AM +0000, epergne%hotmail.com@localhost wrote:
 >   > /usr/include/sys/cdefs.h:1:2: error: #warning usage of non-standard #include <sys/cdefs.h> is deprecated [-Werror=cpp]
 >   >  #warning usage of non-standard #include <sys/cdefs.h> is deprecated
 >  
 >  huzzah for glibc...
 >  
 >  There are two issues here (besides routine glibc stupidity):
 >    (1) the configure script isn't correctly detecting that the system
 >        <sys/cdefs.h> is no good;
 >    (2) the gcc command line contains -Wno-error -Wno-error -Werror
 >  
 >  If the configure script doesn't use -Werror it won't fail on that
 >  warning, hence #1; the question I guess is where that -Werror in the
 >  gcc command line is coming from.
 
 Thanks for getting back to me. I did some digging around to find out
 where the -Werror might be coming from.
 
 Prefixing the bootstrap command with `NOGCCERROR=1` solves the problem.
 i.e.:
 
 NOGCCERROR=1 ./bootstrap --unprivileged
 
 I got the idea after seeing the following in a grep result:
 
 share/mk/bsd.sys.mk:25:CFLAGS+= -Werror
 
 Which appeared to be the only place where that flag is specified.
 
 After seeing the bug report at <https://gnats.netbsd.org/46292>,
 however, I have concerns that my workaround could break something else.
 If so, is there a way to address the core issue?
 
 ~mlr