This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug bootstrap/78251] New: config/gettext.m4 and config/iconv.m4 contaminate CPPFLAGS


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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]