Re: Lintian warning: hardening-no-fortify-functions & version numbering
On Mon, Jun 25, 2012 at 06:55:53PM +0300, Serge wrote:
> 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.
This does not match historical practice.
> BTW, it's interesting that Fedora/CentOS use -Wp,-D_FORTIFY_SOURCE=2
> and they use it in CFLAGS/CXXFLAGS.
Presumably as a workaround for build systems that do not respect
CPPFLAGS.
[...]
> > 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.
[...]
GNU make's implicit rules use CPPFLAGS. If other build systems or
overriden rules don't use it, it's a bug. This can of course be
worked around in debian/rules.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
Reply to: