Boris Kolpackov: > Ximin Luo <infini...@pwned.gg> writes: >> Boris Kolpackov: >> >>> This does feel like we are trying to fix the issue in the wrong place. >>> Also, won't such broken packages normally store all options (including >>> -I) rather than just CFLAGS? And if the answer is no, then perhaps you >>> could put -ffile-prefix-map into CPPFLAGS instead of CFLAGS? Kind of >>> even feels right seeing that it affects the preprocessor. >>> >> >> The broad issue affects -fdebug-prefix-map as well, not just __FILE__. > > -ffile-prefix-map is the "common" option that (currently) > takes care of both debug and macro remapping (and should we > add any new -f*-prefix-map, those as well). > >> Such packages are not "broken"; GCC itself stores command-line >> arguments in DW_AT_producer and as mentioned there was a bug to >> special-case filtering -fdebug-prefix-map out of that. >> >> Now we'll have to add exceptions for -ffile-prefix-map and all >> the other flags you added, and everything else that might be >> added in future. > > -ffile-prefix-map and -fmacro-prefix-map are already excluded. > And there is a note at the appropriate place in source code to > exclude any new -f*-prefix-map should they be added. >
Fair enough, I didn't look at your entire patch. But don't you think stripping the whole value is unnecessary? One advantage of the ENV: approach is that we can remove this filtering, and then the =$to part can be present in DW_AT_producer, indicating the fact that the flag was indeed used, and what the $to value was. That would be helpful for debugging actually. > You also haven't answered my question about -I: don't the > projects that embed CFLAGS also embed CPPFLAGS (and thus > -I's with absolute/varying paths)? And if the answer is > no, then can't you use the same approach to make > -ffile-prefix-map a non-issue? > -I to an absolute path is not that common for system / distro-built stuff. In the cases that it occurs, indeed it could and should be fixed by the package buildsystem, e.g. by stripping a prefix when they add -I flags to CFLAGS. But that's a separate issue from what we're talking about here. One major use-case for this flag, is to be set for all builds by the distribution. (Setting it per-package would be much much more work.) In this case, even if the build is using relative paths for -I and setting $PWD to an relative path for __FILE__ (and this behaviour is not explicitly mentioned in any standard), as long as they save CFLAGS/CPPFLAGS their build would not be reproducible. I don't think it would be fair to impose this behaviour on packages, even if they are doing *everything else correctly* for reproducibility purposes. For example this one, the unreproducibility diff exists because we temporarily reverted to an unpatched dpkg (i.e. it sets -fdebug-prefix-map rather than using the envvar supported by our patched GCC): https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/freeradius.html (Then there are other programs that like to put cflags/cppflags in their --help text for debugging purposes, etc.) It does *everything else right* but the presence of that system-wide flag causes it to be unreproducible. If GCC does not support an envvar or other similar method to pass in this flag, then these packages are the ones that suffer. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
