RFC: dpkg patch to using -ffile-prefix-map

[Vagrant Cascadian]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20180731/3fdf841d/attachment.sig>