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:
/usr/share/strip-nondeterminism/bin/gcc
/usr/share/strip-nondeterminism/bin/g++
etc, with contents
#!/bin/sh
exec "$0" --path-prefix-map="${BUILD_PATH_PREFIX_MAP:-}" "$@"
3. Add a Makefile snippet to strip-nondeterminism:
/usr/share/strip-nondeterminism/mk/build-path.mk
with contents
DEB_BUILD_MAINT_OPTIONS += reproducible=-fixdebugpath
export DEB_BUILD_MAINT_OPTIONS
PATH := /usr/share/strip-nondeterminism/bin:$(PATH)
export PATH
Then, fixing a package affected by (b), (c) or (d) will simply consist of:
d/control:
+Build-Depends: strip-nondeterminism
d/rules:
+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".
X
[1] https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00770.html
--
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git
_______________________________________________
Reproducible-builds mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
