[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

Hi (again)!

On Sat, 9 Jan 2021 at 17:53, Vagrant Cascadian
<vagrant@reproducible-builds.org> wrote:
> On 2021-01-09, Lisandro Damián Nicanor Pérez Meyer wrote:
> > Oh, I have sadly forgotten to mention another thing.
> >
> > On Sat, 9 Jan 2021 at 15:53, Lisandro Damián Nicanor Pérez Meyer
> > <perezmeyer@gmail.com> wrote:
> >> # __FILE__ is a public, well defined API
> >
> > According to:
> > Adrian Bunks mentions it in
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876901#10
> > Holger Levsen in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876901#42
> > Mattia Rizzolo on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876901#192
> >
> > The ability of gcc to change __FILE__ was a patch that, at the time of
> > those writings, wasn't yet accepted.
> That is no longer the case. The fixfilepath feature enabled in dpkg only
> uses features (e.g. -ffile-prefix-map) available in both upstream GCC
> (>=9? or 8? ~2018) and Clang (>= 10), possibly other compilers as
> well. There are no special patches to toolchains needed to enable this
> feature.

This is actually good to read!

> > Even more, Ximion Luo wrote on
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876901#212
> >
> >   The GCC patch (neither the previous nor the planned version) does
> >   not change the default behaviour of __FILE__, and was never intended
> >   to. Instead, it gives users the ability to rewrite __FILE__, more
> >   specifically a prefix of it.
> >
> > makes it clear that the default behaviour is not changed. So if the
> > patch got accepted (did it get accepted?) it was only to allow
> > reproducible people to break API in order to get reproducibility.
> Since then an alternate implementation was implemented that the
> reproducible=+fixfilepath feature in dpkg takes advantage of, in order
> to implement this feature in another distribution, if I recall
> correctly.
> It didn't address all the cases of the old GCC patches that Ximin
> submitted, but the Reproducible Builds team decided in 2018 to make use
> of upstream supported features only and dropped all of our patches to
> GCC.
> The notable difference is that it not longer makes use of an environment
> variable; it requires passing the -ffile-prefix-map option to the
> compiler. The dpkg patch simply adds this to the default relevent *FLAGS
> variables.
> (For historical completeness, though somewhat an aside to the topic at
> hand, the -ffile-prefix-map approach does not address all the cases of
> the former patches to GCC as the compiler flags sometimes end up in
> various shipped artifacts in *some* cases, though certainly not all.)

Again, good to read.

> > This in itself, if something has not changed in the meantime, marks
> > another reference that __FILE__ is a public, well defined API.
> I think reading #876901 demonstrates that the case can be made either
> way; it not as well defined as you make it out to be.

As stated in my previous mail I was wrong here, as demonstrated by
Mattias. I even just updated the base Qt bug accordingly.

Thanks for being so informative too!

Lisandro Damián Nicanor Pérez Meyer

Reply to: