Re: Enabling hardened build flags for Wheezy
* Charles Plessy <plessy@debian.org> [120307 16:27]:
> Thanks (and thanks Cyril) for the hint. Still there are two things
> I do not understand:
>
> - Why and when it is a problem to add preprocessor flags in CFLAGS.
Becuase CFLAGS is not meant for preprocessor flags. Adding stuff in
unexpected places might break correct stuff.
There are usually 4 variables for C/C++ code:
CPPFLAGS is for options for the preprocessor like -D and -I
CFLAGS is flags for the C compiler
CXXFLAGS is flags for the C++ compiler
LDFLAGS if flags for the linker.
The rules are:
- if you call the preprocessor, or a compiler in a way to call the
preprocessor, you give it CPPFLAGS.
- if you call the linker (ideally by calling the compiler in a way
to invoke the linker (i.e. without -c)) you give it LDFLAGS.
- if you call the compiler, you give it CFLAGS (for gcc) or CXXFLAGS
(for g++).
That is you usually have something like (with usually more variables,
as most software needs some hardcoded values that should not go in the
user variables):
g++ $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) bar.cc -o progname
gcc $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) bar.c -o progname
g++ $(CPPFLAGS) $(CXXFLAGS) -c foo.cc -o foo.o
gcc $(CPPFLAGS) $(CFLAGS) -c foo.c -o foo.o
g++ $(CXXFLAGS) $(LDFLAGS) foo.o -o progname
gcc $(CFLAGS) $(LDFLAGS) foo.o -o progname
The reason you should give CFLAGS/CXXFLAGS when giving the compiler a .o
file is that linking might also produce code (when using lto, or when
generating shared libraries, or ...) which needs to get the same
options.
Thus depending on upstream's build scripts, you might need to put
multiple flags in different variables (sometimes putting CPPFLAGS
and CFLAGS in a variable called CFLAGS, sometimes CFLAGS and LDFLAGS
in a variable called LDFLAGS and so on).
> - Why we chose the solution that require more extensive changes
> to the packages.
By having each categorie in its own variable and having those variables
named as the influental GNU coding standards requiring them to be, we
get the possibility to support any system and doing the right thing
automatically for the majority. (Merging values is easy, splitting is
not).
It requires no change for good packages. For packages not following the
usual semantics you will have to find out which flags to put where
anyway, so it does not get more complicated, either.
Also note that if upstream's build system does not support CPPFLAGS,
chances are it does not support LDFLAGS either. So you might want to
look at this and perhaps mangle it into something either).
Another often seen mistake in hand-written Makefiles is using CFLAGS
when compiling c++ code. In the easy case of only having c++ code that
means you might need to give CXXFLAGS into a variable named CFLAGS.
Bernhard R. Link
Reply to: