Re: Lintian warning: hardening-no-fortify-functions & version numbering
On Sun, 2012-06-24 at 11:07:05 +0300, Serge wrote:
> 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).
That would be wrong as -Wp bypassed the compiler driver. And when
calling gcc you are implicitly using the preprocessor anyway. How you
directly call gcc (or cc for that matter) does not have anything to do
with autotools, the latter only standardizes a way to pass flags to
those calls though, and the compiler is suppoed to be called in the
way Russ pointed out.
> >> 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).
The fact that it's called cpp or «gcc -E» should not matter and it's an
implementation detail, both should be performing the same task. If you
need to test for some preprocessed stuff, then there's no point in
compiling anything, instead just preprocessing should be enough.
> > 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...
No one forces you to pass CPPFLAGS to the build system, or for those
build systems to support it, you can always do something like:
make CFLAGS="$(CPPFLAGS) $(CFLAGS)"
for example, but having to split CPPFLAGS after the fact for build
systems that do support it would be extremely annoying.
> 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.
_FORTIFY_SOURCE *is* a preprocesssor macro, you just need to grep for
it in /user/include/, and just to make sure I just checked the gcc
sources and there's no relevant reference to that macro, which the
compiler driver could still be checking for as pointed out above (re
-Wp), so there's something else going on in your compiler call (maybe
implicit optimization settings, an alias, etc?). It also obviously
depends on the preprocessed input, try including <stdio.h> for
example and setting an optimization level > 0 in the preprocessor call.
> 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.
No, as per above, and there's no workaround here, just different build
system conventions, and that's part of the job of the debian/rules
file, otherwise if all build systems used the same conventions we would
not need one at all.
> What do you think? Should this get filled as a bugreport?
>
> PS: Bugs must be fixed, not documented, IMO.
There's no bug here.
ragards,
guillem
Reply to: