Hello
with my little Examine tool, or with the 'sigcheck' tool from
sysinternal, it seems that the TimeDateStamp field of the
IMAGE_FILE_HEADER structure, which is "the date and time the image was
created by the linker" (see
It's not a problem of striping files or not (the debug section is not
involved here). But anyway, i've just did this :
gcc -g -O2 -o pi pi.c
then, I run the sigcheck tool. Here is the output :
$ /sigcheck.exe ./pi.exe
Sigcheck v2.50 - File version and signature viewer
Copyright (C) 2004-2016
Vincent Torri
writes:
> Can someone confirm that ? If yes, is it possible to fix this ?
For obtaining reproducible binaries I had to pass --no-insert-timestamp
to the linker. That was last December, using the MSYS2's MinGW-w64
toolchain (32 bits).
On Sun, Feb 7, 2016 at 6:42 PM, Óscar Fuentes wrote:
> Vincent Torri
> writes:
>
Can someone confirm that ? If yes, is it possible to fix this ?
>>>
>>> For obtaining reproducible binaries I had to pass --no-insert-timestamp
>>> to the linker. That
Vincent Torri
writes:
> my point is that the timestamp is incorrect (it is set to 0, which is wrong)
Yes, that was clear from your first message.
binutils can be cofigured with --enable-deterministic-archives. Maybe
your binutils was configured that way?
Please note
Vincent Torri
writes:
>>> Can someone confirm that ? If yes, is it possible to fix this ?
>>
>> For obtaining reproducible binaries I had to pass --no-insert-timestamp
>> to the linker. That was last December, using the MSYS2's MinGW-w64
>> toolchain (32 bits).
>
> i've
Thanks for all the work on mingw-w64, awesome job.
Might be nice to cut a release as well, I know that FFmpeg dshow
module will soon be having to depend on git master, would be nice to
be able to depend on a release version :)
Cheers!
-roger-