Re: Ximin Luo 2016-09-06 <1f0f5aa5-449b-5bca-7e0b-e8dfab756...@debian.org>
> Well, we could have dpkg-buildflags also set SOURCE_ROOT somehow. A hacky 
> strawman solution, is to patch:
> 
> 1. dpkg-buildflags --export to also define SOURCE_ROOT
> 2. /usr/share/dpkg/buildflags.mk
> 
> Debhelper and CDBS should pull in SOURCE_ROOT automatically via (1), no 
> changes needed.
> 
> However code search 
> https://codesearch.debian.net/search?q=dpkg-buildflags+--get shows that many 
> packages are doing custom things with specific flags, which we would probably 
> break with the above approach. (Many of these results are also using 
> debhelper but (a) it's unclear how this interacts with their custom flags and 
> (b) I imagine quite a lot of them aren't using it.)
> 
> It would likely be easier/safer to just patch GCC directly.

I've been poking around in the PostgreSQL packages a bit more, and the
problem gets worse :(

I've successfully (modulo an actual upload) patched pg_config to
remove -fdebug-prefix-map from the "pg_config --cflags" output, the
build path issue is also present in all extension modules. In current
sid, the extensions are compiled using the server's -fdebug-prefix-map
setting (which doesn't do anything), but then with my fix, the
extensions would be compiled just without any -fdebug-prefix-map
because "pg_config --cflags" says so.

Not sure what to do here. I could tweak pg_buildext (which most
extensions use) to re-add a new -fdebug-prefix-map flag. But
everything would just be much easier if dpkg-buildflags and gcc would
use -fdebug-prefix-map=SOURCE_ROOT=., in which case I could leave
pg_config unpatched, and the same CFLAGS would also work for all
extension modules, just with a different SOURCE_ROOT setting.

Christoph

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Reply via email to