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
Description: PGP signature
_______________________________________________ Reproducible-builds mailing list Reproducibleemail@example.com http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds