Re: Enabling hardened build flags for Wheezy
Charles Plessy <firstname.lastname@example.org> writes:
> all our packages include a way to pass build flags to the upstream build
> system, in order to implement features such as DEB_BUILD_OPTIONS=noopt.
> It would have been trivial to pass the hardening flags automatically
> through the same communication channel.
I don't understand what you mean. Explicit logic is required in
debian/rules to handle DEB_BUILD_OPTIONS=noopt unless you use a helper
system that embeds that logic. There's nothing magic about that. dh
deals with it for you, of course, but it's no different so far as I can
tell from the way hardening flags were implemented, except that it's much
simpler to change the optimization level than it is to harden all the
parts of the build.
> Unfortunately, the hardening build flags have been split in three
> variables. To make sure they are passed correctly, either the upstream
> makefiles have to be modified, or debian/rules has to be modified.
Well... it's usual to have to modify debian/rules to adjust to new
features of the Debian build system, no? It's a pretty simple one-time
change, isn't it?
> Why couldn't we design a solution that does not require these
> modifications except for corner cases ?
We did... that's dh. dh 9 just picks up hardening flags and just works
without any changes required for any Autoconf-enabled package, or for any
package with another build system that it understands.
> It does not matter that they are trivial, the point is that if most C
> programs need to have the same override in debian/rules, it feels that
> there is something wrong.
Most C programs use Autoconf in my experience. I know that scientific
software often doesn't, but I think scientific software is the significant
outlier in that respect.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>