[GRASS-dev] [GRASS GIS] #2916: configure bug (?): FORTIFY_SOURCE in CPPFLAGS breaks configure on Arch Linux

[GRASS GIS]

#2916: configure bug (?): FORTIFY_SOURCE in CPPFLAGS breaks configure on Arch
Linux
------------------------+-------------------------
  Reporter:  msieczka   |      Owner:  grass-dev@…
      Type:  defect     |     Status:  new
  Priority:  normal     |  Milestone:  7.0.4
 Component:  Compiling  |    Version:  7.0.3
Resolution:             |   Keywords:
       CPU:  All        |   Platform:  Linux
------------------------+-------------------------

Comment (by glynn):

 Replying to [comment:12 msieczka]:

 > If understand what you are saying, the following would be better
 (putting aside your point against forcibly enabling _FORTIFY_SOURCE at
 all):
 >
 {{{
 export CFLAGS="$CPPFLAGS $CFLAGS"
 export CXXFLAGS="$CPPFLAGS $CXXFLAGS"
 unset CPPFLAGS
 }}}

 The problem with this is that it breaks any case where the preprocessor is
 run standalone, rather than as part of compilation.

 I don't think that happens anywhere within actual the GRASS build process,
 as Platform.make.in doesn't mention @CPP@ anywhere (so there's no valid
 way for a Makefile to know how to run the preprocessor by itself).

 But it can create problems for the configure script, which uses the pre-
 processor extensively. E.g. AC_CHECK_HEADERS is based upon AC_TRY_CPP, so
 if it needs e.g. any -I switches from CPPFLAGS, moving those into
 CFLAGS/CXXFLAGS will break it.

 > Do you know whether all (sane) CPPFLAGS can be safely be mixed into
 CXXFLAGS and CFLAGS like this?

 That isn't a problem. The C compiler is always passed both $(CFLAGS) and
 $(CPPFLAGS), while the C++ compiler is always passed both $(CXXFLAGS) and
 $(CPPFLAGS). If the preprocessor is run separately, it should only be
 passed $(CPPFLAGS), hence the distinction.

 > And what do you think about scimmia's "ancient version of autoconf used"
 #comment:1? I mean could using a newer autoconf version to generate the
 GRASS configure script fix the problem?

 Maybe. Like many autoconf macros, AC_PROG_CPP runs through a fixed set of
 candidates until one appears to work. It's possible that a newer version
 has more candidates. Or it's possible that it's smarter at ignoring
 warnings from the preprocessor.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2916#comment:13>
GRASS GIS <https://grass.osgeo.org>