Hi (again)! On Sat, 9 Jan 2021 at 17:53, Vagrant Cascadian <vagr...@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 > > <perezme...@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 http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
