https://sourceware.org/bugzilla/show_bug.cgi?id=30702
Bug ID: 30702 Summary: objcopy and strip invalidate the effect of ld option --no-insert-timestamp Product: binutils Version: 2.40 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: christian.fra...@t-online.de Target Milestone: --- The ld option '--no-insert-timestamp' is useless if objcopy or strip is used afterwards. This is common practice in packaging support tools like Cygwin's cygport to create separate packages with debug information. Testcase with MinGW-w64 binutils 2.40 on Cygwin: $ echo 'int main() {return 0;}' \ | x86_64-w64-mingw32-gcc -xc -Wl,--no-insert-timestamp -o nostamp.exe - $ x86_64-w64-mingw32-objdump -p nostamp.exe | grep Time/Date Time/Date Thu Jan 1 01:00:00 1970 $ x86_64-w64-mingw32-strip nostamp.exe $ x86_64-w64-mingw32-objdump -p nostamp.exe | grep Time/Date Time/Date Mon Jul 31 09:02:52 2023 Observed behavior: Timestamp is set to current time/date. Expected behavior: Null timestamp is left as is. This breaks reproducible builds. Long term experience with many false positive virus reports (in smartmontools project) shows that removed false positives may immediately reappear in rebuilds from same source with same toolchain simply because the file has a new timestamp (and checksum). Further possible enhancements: - If objcopy/strip option '-D, --enable-deterministic-archives' is specified, also leave a non-null timestamp as is. - Allow to set the timestamp to a specific value to support builds with SOURCE_DATE_EPOCH set. This would also help in situations where a null timestamp could not be used (Bug 16887). -- You are receiving this mail because: You are on the CC list for the bug.