bug-grep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15663: _FORTIFY_SOURCE compilation error: Redefinition with GCC 4.7.


From: behoffski
Subject: bug#15663: _FORTIFY_SOURCE compilation error: Redefinition with GCC 4.7.3 under Gentoo
Date: Sun, 20 Oct 2013 17:54:51 +1030
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130911 Thunderbird/17.0.9

G'day,

I've been building the latest Git sources for GNU Grep on a Gentoo
system.  Using GCC-4.6.3, the update/reload command:

        git pull ; ./bootstrap ; ./configure ; make ; make check

works fine.  However, if I switch to GCC-4.7.3, the compilation
fails when compiling lib/argmatch.o:

        make  all-am
        make[3]: Entering directory `/home/grep-2.14/grep/lib'
          CC     argmatch.o
        In file included from argmatch.c:22:0:
        ../config.h:72:0: error: "_FORTIFY_SOURCE" redefined [-Werror]
        argmatch.c:1:0: note: this is the location of the previous definition
        cc1: all warnings being treated as errors
        make[3]: *** [argmatch.o] Error 1
        make[3]: Leaving directory `/home/grep-2.14/grep/lib'
        make[2]: *** [all] Error 2

Scrounging around on the 'net a bit, it seems that Debian and others are now
"#defining _FORTIFY_SOURCE 2" as a default preprocessor definition in the
latest releases of gcc, and this has flowed on to the Gentoo 4.7.3 version.
(I haven't checked intervening gcc versions.)

The collision happens because of a rule in configure.ac, where, if __OPTIMIZE__ 
is
defined and is true, then _FORTIFY_SOURCE=2 is defined.  The code injected into
config.h does not expect that an earlier definition is present, and this causes
the conflict:

          AH_VERBATIM([FORTIFY_SOURCE],
          [/* Enable compile-time and run-time bounds-checking, and some 
warnings,
              without upsetting glibc 2.15+. */
           #if defined __OPTIMIZE__ && __OPTIMIZE__
           # define _FORTIFY_SOURCE 2
           #endif
          ])

I can suggest two ways of dealing with this: Either respect any previous 
definition:

           #if defined __OPTIMIZE__ && __OPTIMIZE__ && ! defined _FORTIFY_SOURCE
           # define _FORTIFY_SOURCE 2
           #endif

or, discard any previous directive and enforce fortification regardless:

           #if defined __OPTIMIZE__ && __OPTIMIZE__
           # undef _FORTIFY_SOURCE
           # define _FORTIFY_SOURCE 2
           #endif

It's probably worth sorting this out before releasing 2.15.

cheers,

behoffski (Brenton Hoff)
Programmer, Grouse Software





reply via email to

[Prev in Thread] Current Thread [Next in Thread]