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.
