3 ms·

I don't know why you blame GCC. It doesn't stuff any such metadata into binaries on its own, but because it was asked to do so. Also, I'm pretty sure most repro

by jwilk 9y ago

I don't know why you blame GCC. It doesn't stuff any such metadata into binaries on its own, but because it was asked to do so. Also, I'm pretty sure most reproducibility issues has nothing to do with a C compiler anyway.

taeric 9y ago
The parts of the compiler that kill reproducibility, I had thought, were the optimizations. Which can be a non-deterministic search of an optimization space nowdays.
- TheDong 9y ago
  Please provide a citation. To my knowledge, that is not true. Debian's reproducible build project has not encountered any issue with optimizations as far as I know, so it seems like your claim would need significant evidence.
  - taeric 9y ago
    To be fair, I did have a qualifier there. :) I could have sworn I saw this discussed somewhere before, but I can't find an article now. I can find that some branch prediction is non-deterministic. Though, in all of those cases, you can specify the random seed, so not likely to be an actual problem.
- madez 9y ago
  Even if a compiler used "random" inputs for profiling, they could come from a deterministic pseudo random number generator that returns the same result on each compilation.
  - taeric 9y ago
    Yeah, that is what I guessed down thread. I just latched onto "non-deterministic."
jwilk 9y ago
> [GCC] doesn't stuff any such metadata into binaries on its own Correction: when you build with debug information enabled (-g), GCC does put current working directory into the binary. This could be fixed with the -fdebug-prefix-map=… option, but when Debian folks tried it, they run into other reproduciblity problems: https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00513.html https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00513.html Anyway, my point is that the road to reproducible builds is not obstructed just by one big thing (GCC). There are lots of obstacles of various shapes and sizes: https://tests.reproducible-builds.org/debian/index_issues.html https://tests.reproducible-builds.org/debian/index_issues.ht...

by jwilk 9y ago

taeric 9y ago

The parts of the compiler that kill reproducibility, I had thought, were the optimizations. Which can be a non-deterministic search of an optimization space nowdays.

TheDong 9y ago
Please provide a citation. To my knowledge, that is not true. Debian's reproducible build project has not encountered any issue with optimizations as far as I know, so it seems like your claim would need significant evidence.
- taeric 9y ago
  To be fair, I did have a qualifier there. :) I could have sworn I saw this discussed somewhere before, but I can't find an article now. I can find that some branch prediction is non-deterministic. Though, in all of those cases, you can specify the random seed, so not likely to be an actual problem.
madez 9y ago
Even if a compiler used "random" inputs for profiling, they could come from a deterministic pseudo random number generator that returns the same result on each compilation.
- taeric 9y ago
  Yeah, that is what I guessed down thread. I just latched onto "non-deterministic."

jwilk 9y ago

> [GCC] doesn't stuff any such metadata into binaries on its own Correction: when you build with debug information enabled (-g), GCC does put current working directory into the binary. This could be fixed with the -fdebug-prefix-map=… option, but when Debian folks tried it, they run into other reproduciblity problems: https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00513.html https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00513.html Anyway, my point is that the road to reproducible builds is not obstructed just by one big thing (GCC). There are lots of obstacles of various shapes and sizes: https://tests.reproducible-builds.org/debian/index_issues.html https://tests.reproducible-builds.org/debian/index_issues.ht...