2012/6/24 Guillem Jover wrote:
>> 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.
Yes, that's the point! If user wanted to pass parameters to the compiler,
he would used CFLAGS/CXXFLAGS. And since he used CPPFLAGS I assume that he
wanted to pass them to the preprocessor, not compiler. So when invoking
gcc build system must prepend CPPFLAGS with -Wp.
BTW, it's interesting that Fedora/CentOS use -Wp,-D_FORTIFY_SOURCE=2
and they use it in CFLAGS/CXXFLAGS.
> No one forces you to pass CPPFLAGS to the build system
Ah, no, I did not mean that. I just mean that not every build system
support CPPFLAGS, and even those who support it, do it in different
ways. So if "dpkg" wants to be easy to use with many build systems,
it should stick to CFLAGS/CXXFLAGS, and avoid using CPPFLAGS if that
is possible.
> you can always do something like:
> make CFLAGS="$(CPPFLAGS) $(CFLAGS)"
It's not just I "can". As long as dpkg uses CPPFLAGS I must do that.
And the "must" is there only because of dpkg-buildflags. I would not
have to do that if dpkg was not setting CPPFLAGS.
> having to split CPPFLAGS after the fact for build systems that do
> support it would be extremely annoying.
I agree. It may not be a good idea in general. But in our case the
-D_FORTIFY_SOURCE=2 option does not have to be split, so it's not
a problem. After all CPPFLAGS without CFLAGS are only used by
./configure tests, and this option does nothing for them.
> _FORTIFY_SOURCE *is* a preprocesssor macro, you just need to grep for
> it in /user/include/ [...] try including <stdio.h> for example and
> setting an optimization level > 0 in the preprocessor call.
Right, my bad. When I checked that on my machine I did:
$ cpp test.cpp | md5sum
$ cpp -D_FORTIFY_SOURCE=2 test.cpp | md5sum
$ g++ -O2 -c test.cpp && md5sum test.o
$ g++ -O2 -D_FORTIFY_SOURCE=2 -c test.cpp && md5sum test.o
But running `cpp -O2 ...` actually makes the difference. In my defence
I can only say that this option is not documented in `man cpp`.
Looks like "-O2" is a preprocessor option too.
> No, as per above, and there's no workaround here, just different build
> system conventions.
Yes. There're different system conventions. But still dpkg-buildflags
should do something. Currently it sets: CFLAGS, CXXFLAGS, FFLAGS, LDFLAGS
and CPPFLAGS. Why it sets just these? Why doesn't it set, for example
CMAKE_C_FLAGS, or QMAKE_CXXFLAGS instead? It's because those are the most
popular flags, right? All of them are supported by most build systems.
All of them except CPPFLAGS.
Currently autotools packages must write rules in one way, while packages
of other build systems must do it in another. Why? Why dpkg prefers one
build system to the others? It's really trivial to make dpkg compatible
with almost all the build systems around by just dropping CPPFLAGS. This
will make packaging easier. Why not do that?
>> PS: Bugs must be fixed, not documented, IMO.
>
> There's no bug here.
There's a workaround. It means there's a bug being workarounded.
Since it's about dpkg and cmake, the bug is either in dpkg, or cmake
or somewhere between them. Since it happens for other build systems,
I tend to think it's in dpkg.
I'm not telling that nobody must ever use CPPFLAGS. As Russ Allbery wrote
it's necessary to use it if you have std-includes in an unusual location.
What I suggest is to not use CPPFLAGS when it's not needed.
To make it shorter. Dpkg-buildflags must set -D_FORTIFY_SOURCE=2 somewhere.
There're options:
1. Put -D_FORTIFY_SOURCE=2 to CPPFLAGS (autotools)
advantages: none?
disadvantages: makes [cq]make packaging a little bit harder
2. Put -D_FORTIFY_SOURCE=2 to CFLAGS/CXXFLAGS
advantages: makes any packaging a little bit easier
disadvantages: none?
3. Put _FORTIFY_SOURCE=2 to DEFINES (qmake)
advantages: none?
disadvantages: makes autotools packaging a little bit harder
4. Put it to any other variable XXX
advantages: none?
disadvantages: makes any packaging a little bit harder
I'm for #2.
The "it belongs to CPPFLAGS" thing is neither advantage nor disadvantage,
because it also belongs to CMAKE_C_FLAGS, CMAKE_CXX_FLAGS, QMAKE_CXXFLAGS
or even qmake's DEFINES option, and probably a lot of other variables of
different build systems around. It does not mean that dpkg-buildflags
should set them all.
Also if you consider "it belongs to CPPFLAGS" an important argument,
you should move "-O2" to CPPFLAGS too, because -D_FORTIFY_SOURCE=2
is a preprocessor option only together with -O2, it does nothing
without it (see above).
Yes, "it belongs to CPPFLAGS" is a good argument when you're trying to
convince someone, but it's not really an advantage, it does not make
anything better.
PS: thanks to Russ Allbery for detailed *FLAGS description, it helped me
to understand the origins.
--
Let's make packaging easier,
Serge
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAOVenEqqDjae9kbpm6SWKTHyK3yrXkJKw2RVcScQxvBUb8Tr7 w@mail.gmail.com">http://lists.debian.org/CAOVenEqqDjae9kbpm6SWKTHyK3yrXkJKw2RVcScQxvBUb8Tr7 w@mail.gmail.com
Lintian warning: hardening-no-fortify-functions & version numbering
