Ansgar <[email protected]> writes:
> with the upcoming time_t & friends 64-bit transition, dpkg-buildflags
> will be used to configure the ABI in use. Thus all compiler
> invocations *must* use the flags specified by dpkg-buildflags to avoid
> ABI inconsistencies like this one:
> struct T { time_t a; time_t b; };
> If this struct is accessed from both `libfoo1t64` (built respecting
> dpkg-buildflags and thus time_t is 64-bit) and `bar` (built by a user
> invoking gcc themselves), the result is probably not what one wants.
> Thus `dpkg-buildflags` *must* be used by all packages *and* all users,
> including users building their own software. There is one exception
> when libraries provide both 32-bit and 64-bit time_t ABIs like glibc
> itself (but I doubt there are many of those).
> Any compiler invocation missing these *should* be a serious bug.
> (This should probably be mentioned in user documentation as well.)
> Currently Debian Policy does not mention dpkg-buildflags at all.
This seems correct to me. We can at least make it a should in Debian
Policy, and I can see the argument that it might be a must given the
issues with time_t on 32-bit architectures.
I'm not sure the best place to start with this given that we currently
don't talk about dpkg-buildflags at all, as you point out. Maybe it's as
simple as adding a 4.9.3 section along the following lines?
This is very rough wording; feedback welcome. In particular, I'm a bit
worried this is too strong when it comes to flags from dpkg-buildflags
that are fine to override, such as changing the optimization level.
``debian/rules`` and dpkg-buildflags
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Source packages that invoke a compiler that is supported by
:command:`dpkg-buildflags` should use that command to obtain the default
flags to pass to the compiler. See :manpage:`dpkg-buildflags(1)` for more
information. In many cases, this is handled automatically by the ``dh``
tool provided by the debhelper package.
Packages that require special handling of compiler flags may selectively
override the results of :command:`dpkg-buildflags` or avoid that command
entirely, but only if the package maintainer is prepared to track future
changes to the default compiler flags and update the package accordingly.
This is normally only appropriate for packages such as ``glibc`` that have
unique build considerations.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
