GCC build-path patch getting blocked

Ximin Luo infinity0 at debian.org
Wed Aug 16 15:40:00 UTC 2017

Hi list,

It looks like the GCC reviewer that looked at my patch this time around, really doesn't like environment variables. They seem to be happy to support the variable (including the syntax) as a command-line flag however.

The original patch fixed ~1800 packages, which were unreproducible due to a combination of (a) __FILE__, (b) CFLAGS et al being embedded into the output, and (c) packages/upstreams not honoring CFLAGS in the first place, and (d) possibly other reasons.

Upstream are essentially arguing that fixing (c) is the proper way forward, but I don't think this is realistic, and unnecessarily couples two separate problems together - IMO reproducibility is not a CFLAGS issue, see e.g. a voice of support at [1]. It also doesn't fix (b); the only way to fix (b) is to add logic to build scripts to strip out a particular command-line flag, in the same way that we patched GCC to strip it out from DW_AT_producer. I don't think this is a clean solution either, reproducibility should come "by default" and most people shouldn't have to add complex logic to their own build scripts.

For these reasons, I have the following proposal, as a work around for the time being:

1. Patch GCC to support BUILD_PATH_PREFIX_MAP as a command-line flag. this will at least fix packages affected by (a).

2. Add `gcc` (et al) wrappers to strip-nondeterminism:
   etc, with contents

   exec "$0" --path-prefix-map="${BUILD_PATH_PREFIX_MAP:-}" "$@"

3. Add a Makefile snippet to strip-nondeterminism:
   with contents

   DEB_BUILD_MAINT_OPTIONS += reproducible=-fixdebugpath
   PATH := /usr/share/strip-nondeterminism/bin:$(PATH)
   export PATH

Then, fixing a package affected by (b), (c) or (d) will simply consist of:

+Build-Depends: strip-nondeterminism
+include /usr/share/strip-nondeterminism/mk/build-path.mk

which will be much much quicker than going in and doing more invasive patches.

This idea is similar to hardening-wrapper. That is now deprecated, but was useful as a stepping-stone to more "proper" fixes. Likewise, this shouldn't be thought of as "the proper fix", but will give us some useful data on how many packages are affected by which combinations of (a), (b), (c) or (d). Depending on the number of packages we will have to patch (with that 2-line patch), it will maybe give weight to future attempts to have GCC support this env var - and then it would be easy, since the core functionality would already be in there - or else highlight the issue so that maintainers of those packages fix things "properly".


[1] https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00770.html 

GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE

More information about the Reproducible-builds mailing list