[Reproducible-builds] Minimising work needed for this build-path issue

Christoph Berg myon at debian.org
Sun Sep 4 14:00:02 UTC 2016


Re: Ximin Luo 2016-08-24 <ae3e9d2c-6191-04fb-5360-259886366f89 at debian.org>
> However, I am not sure if this is the best approach. At present, the output of dpkg-buildflags is itself dependent on the build-path, and some packages *might* save this value somewhere in their output. (This is the case for perl, although in perl's specific case this seems fixable.)

Fwiw, PostgreSQL is hit by this, because:

$ pg_config --cflags
-Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -g -O2 -fdebug-prefix-map=/build/postgresql-9.6-IP43WX/postgresql-9.6-9.6~rc1=. -fstack-protector-strong -Wformat -Werror=format-security -I/usr/include/mit-krb5 -fPIC -pie -fno-omit-frame-pointer

The idea is that these CFLAGS will be used when compiling server
extensions. Granted, in that scenario the original -fdebug-prefix-map
will be useless, so stripping it away will likely improve things, but
I still have to mess with the guts of the server build system to make
that happen.

The SOURCE_ROOT idea sounds sane to me. It would also nicely carry
over to extensions built later with these CFLAGS.

Christoph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20160904/ffd4b403/attachment.sig>


More information about the Reproducible-builds mailing list