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

[Guillem Jover]

Hi!

On Tue, 2018-07-31 at 08:29:33 +0800, Vagrant Cascadian wrote:
> With gcc 8 being the default compiler in debian now, we should be able
> to use -ffile-prefix-map, which should handle *some* of the cases that
> BUILD_PATH_PREFIX_MAP is intended to solve. It definitely won't help
> with things that embed the gcc commandline into arguments.
> 
> But since we've been unable to convince gcc on the merits of
> BUILD_PATH_PREFIX_MAP using an environment variable, rebasing the gcc
> patches to support it takes a lot of effort, perhaps we should explore
> other options.
> 
> 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.

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.

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.

> 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? :)

> 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 :).

Thanks,
Guillem
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Dpkg-Vendor-Debian-Add-fixfilepath-to-reproducible-f.patch
Type: text/x-diff
Size: 3427 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20180731/206103c7/attachment.patch>