This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug bootstrap/78251] New: config/gettext.m4 and config/iconv.m4 contaminate CPPFLAGS
- From: "howarth.at.gcc at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 08 Nov 2016 12:32:34 +0000
- Subject: [Bug bootstrap/78251] New: config/gettext.m4 and config/iconv.m4 contaminate CPPFLAGS
- Auto-submitted: auto-generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78251
Bug ID: 78251
Summary: config/gettext.m4 and config/iconv.m4 contaminate
CPPFLAGS
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth.at.gcc at gmail dot com
Target Milestone: ---
While debugging the MacPorts build approach for FSF gcc and comparing it to our
own in the fink project, I ran across a surprising result. The MacPorts project
builds fail when their libunwinder-headers package is installed in their
${prefix} which is /opt/local. I expected to be able to solve this by building,
like fink, with CPPFLAGS and LDFLAGS unset (i.e. no -I/opt/local/include on
CPPFLAGS and -L/opt/local/lib on LDFLAGS) but instead to rely on the individual
--with-*= configure options to sort the paths out.
Weirdly the build starts out fine and the initially generated Makefiles always
retain...
CPPFLAGS=
but once the build hits any configure which used config/gettext.m4 or
config/iconv.m4, CPPFLAGS gets contaminated with INCICONV or LIBICONV_INCLUDE.
Why can't config/gettext.m4 and config/iconv.m4 be restructured to perform its
tests without contaminating the previous contents of CPPFLAGS in the process?