https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101473
Bug ID: 101473 Summary: LTO makes debug info depend on toolchain path Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: tonyb at cybernetics dot com CC: marxin at gcc dot gnu.org Target Milestone: --- When compiling with -flto -g, the resulting debug info varies depending on the install path of the compiler toolchain. This is a problem for reproducible builds (https://reproducible-builds.org/) when the compiler toolchain is installed in the user home directory. For example, when compiling a file lto_test.c with the same toolchain copied into two different paths, readelf -a shows the following: toolchain path 1: 23: 00000000000005f5 0 NOTYPE WEAK HIDDEN 28 lto_test.c.79b8ff9a toolchain path 2: 42: 00000000000005f5 0 NOTYPE WEAK HIDDEN 28 lto_test.c.bba5e59b The -frandom-seed flag does not help in this case. The output is deterministic (same output across multiple runs). With -flto disabled, the problem goes away. Non-LTO binaries are identical regardless of the compiler toolchain path. Stripping the debug info from the LTO binaries makes them identical, but using "objcopy --add-gnu-debuglink" makes them different again because the embedded checksum for the debug info is different. I encountered this problem trying to make reproducible builds with -flto under Yocto. Here is the Yocto bug report, including test code for Yocto: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14481 Regarding the "LTO reproducible build test" attachment in the Yocto bug report: Yocto sets up the compiler toolchain in a "recipe-sysroot-native" directory and the system lib/, include/, and such in a "recipe-sysroot" directory, which are prepared by running "bitbake lto-test". Then the run-lto-test script makes two copies of the compiler toolchain under two differnet names using "cp -rl", compiles the simple test program using both toolchains, and compares them. Comment 6 on this bug may be related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66305#c6