On 2018-07-31, Guillem Jover wrote: > On Tue, 2018-07-31 at 08:29:33 +0800, Vagrant Cascadian wrote: >> I've got a dpkg patch which makes use of -ffile-prefix-map. I haven't >> found a good test case yet... package that fails to build reproducibly >> due to using __FILE__, __BASE_FILE__, or __builtin_FILE() and builds >> fast enough that it's easy to test (holger suggested trying "dtkwm", but >> I haven't had a chance to try yet). Figured I'd at least publish my >> patch to get some review and/or testers. > > Hah! Just several hours ago I was talking with Mattia over IRC about > the status of this, and ended up cooking the attached patch, which at > his request didn't merge, because he wanted to give it a try first.
Heh. > And yeah, I also kind of understand gcc's upstream position, that if > you unconditionally embed all build flags into your resulting objects, > then they are really bound to be unreproducible, and as such that's > arguably a bug to fix there probably. I get that argument, though I fear that becomes an eternal game of whack-a-mole. > Also AIUI this divergence and the lack of forward porting is the > reason the repro buildds are currently stopped? If so I think getting > something going, even if it might produce some new (or old :) > reproducible problems is probably better than the current situation. Agreed. >> The patch largely just copy-and-pastes the -fdebug-prefix-map code, >> though arguably could obsolete it entirely, since -ffile-prefix-map >> effectivly sets both -fdebug-prefix-map and -fmacro-prefix-map. But >> having the two features independently allows enabling or disabling one >> or the other easily for now. > > I think the semantics in mine are slightly better? :) Surely! Glad to see you've done it properly. >> If nothing else, carrying a patch on dpkg builds *much* faster than gcc, >> and rebasing it periodically will be a lot less effort. Though if it >> works, hopefully we can get it into dpkg directly. > > From my side, I see no problem with merging something like the > attached patch if it works (I've not even run the test suite on it I > think :). Great! > --- a/scripts/Dpkg/Vendor/Debian.pm > +++ b/scripts/Dpkg/Vendor/Debian.pm > @@ -100,6 +100,7 @@ sub _add_build_flags { > }, > reproducible => { > timeless => 1, > + fixfilepath => 0, > fixdebugpath => 1, > }, > sanitize => { So by default, it would be disabled initially, and then we could explicitly enable this for the reproducible builds test framework? After it proves to be working and useful and not disruptive, I presume we would enable it by default? live well, vagrant
signature.asc
Description: PGP signature