Re: Lintian warning: hardening-no-fortify-functions & version numbering
2012/6/24 Russ Allbery wrote:
>> If you do, then... How should they do that? I.e. if I specify:
>> CPPFLAGS="blablabla hehehe hohoho"
>> How should build system run gcc? Like that?
>> gcc blablabla hehehe hohoho -c -o test.o test.c
Why? Just to have it autotools-compatible? If I was writing a custom
build system I would be thinking about using -Wp option, since that's
exactly why it's there for — to pass some options to the preprocessor
(or, being honest, I would ignore CPPFLAGS unless I use the preprocessor).
>> Is there a standard common for all the build systems? Or some kind of
>> recommendation? Or it's just a coincidence that all the build systems
>> use same environment variable CFLAGS?
> CFLAGS is an old, long-standing make thing. CPPFLAGS is newer and I
> believe was introduced by Autoconf, since Autoconf has historically wanted
> to run tests that only use the preprocessor and not the compiler (for
> checking header files, for example), at which point it needed some way of
> distinguishing between the flags. GNU software and other software that
> closely follows the Autoconf and Automake manuals uses a similar
> separation, and it's important to follow that separation when passing
> flags to configure to handle tests where just the preprocessor is run.
> (If, for example, you put the -I flags in CFLAGS and not CPPFLAGS, you may
> find that Autoconf probes won't find header files that are on non-standard
> -I paths.)
You mean, `cpp` is (was?) used only for tests done by ./configure?
I was not thinking about that. Thank you for pointing that out. I just
checked a few random autotools-based programs, and indeed they use
$CPP variable (they actually use `gcc -E`, not `cpp` for it).
> Since the Autoconf/Automake variable naming is the closest we have to a
> de facto standard (and is *extremely* widespread in free software), the
> variable names for the dpkg build infrastructure followed the same
It depends on whether dpkg is trying to force standards or be compatible
It's bad there's no some common standard or RFC about that. Since CPPFLAGS
is used by ./configure only, and ./configure script is autotools-specific,
it makes CPPFLAGS autotools-specific as well, and there's no reason to
demand from other build systems to use it. :(
And cmake is not the only one. At least mplayer's Makefile ignores
CPPFLAGS (`make CPPFLAGS=-Isomedir` will work for autotools, but not
for mplayer). There may be others...
Another point is that the option we're talking about (-D_FORTIFY_SOURCE=2)
isn't actually a preprocessor option. Preprocessor option is some option,
that is supposed to affect preprocessor output. But both:
cpp -D_FORTIFY_SOURCE=2 test.c
will produce exactly same output. While these:
gcc -c test.c
gcc -D_FORTIFY_SOURCE=2 -c test.c
will give different outputs. So despite it *looks* like a preprocessor
option (-D...), it's not used by preprocessor, it's a compiler option,
and belongs to CFLAGS/CXXFLAGS.
So the suggestion is:
if dpkg aims to be compatible with different build systems:
move -D_FORTIFY_SOURCE=2 from autotools-specific CPPFLAGS to commonly
used CFLAGS/CXXFLAGS where it belongs (since it's not a preprocessor
option). This will fix the problem with `cmake` not using preprocessor
and not checking for CPPFLAGS, make dpkg more compatible with existing
build systems, and make packaging easier with no workarounds.
Then we'll be able to remove a "cmake workaround" from the wiki page:
What do you think? Should this get filled as a bugreport?
PS: Bugs must be fixed, not documented, IMO.
PPS: crossposted to debian-dpkg