What is all this about?

dpkg-buildflags allows a uniform setting of default build flags for code written in C and C++. If your package is written in Java, pure Python, pure Perl or shell you don't need to do anything. Good, isn't it?

Uniform build flags have a number of benefits:

* dpkg-buildflags exports hardened build flags. These hardened build flags enforce more stringent checks both at compile time (detects potential security problems during compilation, helps spots regressions) and enables/nullifies yet undetected security problems. The hardened build flags are explained in more depth here.

* dpkg-buildflags allows rebuilding Debian with new/modified flags. If e.g. someone wants to rebuild Debian for an embedded system with -Os instead of -O2, all it needs is to patch dpkg-buildflags instead of thousands of source packages.

* dpkg-buildflags supports DEB_BUILD_OPTIONS=noopt (policy 4.9.1) Right now only a few packages support it, while dpkg-buildflags directly emits emits -O0 if noopt is set.

Enabling dpkg-buildflags in your package is two-fold. On the one hand you need to activate the flags your debian/rules file, on the other hand you need to ensure that the buildsystem of your code abides the necessary flags.

Enabling dpkg-buildflags in your debian/rules files

rules files based on debhelper and minimised dh(1)

If you have already converted your rules file to the minimised dh(1) form, enabling dpkg-buildflags is fairly easy: If you upgrade to compat level 9, they will be auto-injected during build. If you want to stay with earlier compat levels, you can still inject the build flags by passing them to dh_auto_configure, e.g.

override_dh_auto_configure:
       dh_auto_configure -- $(shell dpkg-buildflags --export=configure)

rules files based on standard debhelper or hand-written rules files

If your build file uses the standard debhelper format, the way of injecting the flags depends on your build system. If it's based on the autotools, passing the exported form of dpkg-buildflags to the configure script is usually needed, e.g.

../configure --prefix=/usr $(shell dpkg-buildflags --export=configure) 

If your build system reads the values from standard environment variables like CFLAGS, CXXFLAGS, CPPFLAGS or LDFLAFS, you often need to export these values at the beginning of your rules files. The simplest way to achieve this is to include the following snippet from dpkg at the beginning of your rules file:

DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/buildflags.mk

This will export all the needed flags.

rules files based on cdbs

cdbs already exports CFLAGS from dpkg-buildflags and it will soon be fixed to also export CPPFLAGS and LDFLAGS. If your package uses cdbs you will usually only need to verify, whether your upstream buildsystem properly follows these flags. The relevant cdbs bug is bug 651964

Handling dpkg-buildflags in your upstream build system

To fully support all hardened build flags in your upstream buildsystem, please ensure that the following flags are supported:

CFLAGS, CPPFLAGS and LDFLAGS for code written in C CXXFLAGS, CPPFLAGS and LDFLAGS for code written in C++

buildsystems based on the autotools

If your buildsystem is based on autotools it usually requires no further modifications. If might however occur that some variables are hard-coded in one of the Makefile.in files. An examples for this can be found at bug 655870

Handwritten Makefiles

If your package uses a home-grown buildsystems you first need to check, whether it abides the above-mentioned flags. If not, you can either add the dpkg-buildflags calls directly as part of your Debian-specific modifications. Another solution would to fix the Makefiles to source an already existing environment variable.

Many home-grown Makefiles already support CFLAGS and LDFLAGS, but not CPPFLAGS. In most cases you can simply append CPPFLAGS to CFLAGS, e.g.

CFLAGS = dpkg-buildflags --get CFLAGS CFLAGS += dpkg-buildflags --get CPPFLAGS

buildsystems for Perl modules

The conversion of Perl modules is not yet fully researched, information will be added later.

buildsystems using cmake

The conversion of buildsystems based on cmake is not yet fully researched, information will be added later.