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
>
> Yes.
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
> conventions.
It depends on whether dpkg is trying to force standards or be compatible
with them.
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 test.c
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:
http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake
What do you think? Should this get filled as a bugreport?
PS: Bugs must be fixed, not documented, IMO.
PPS: crossposted to debian-dpkg
--
Serge
Reply to: