Every time I compile the same code with DMD, I get a slightly different ".exe" file on Windows.

fc /b basil.exe basil_old_1.exe
00000118: 9F 55
00000119: 8C 89
00156554: 9F 55
00156555: 8C 89

fc /b basil.exe basil_old_2.exe
00000118: 9F 1B
00000119: 8C 8A
00156554: 9F 1B
00156555: 8C 8A

This problem is D specific, as for instance Go will generate the same executable each time.

So before I implement a tool for this, is there an easy way to prevent DMD from "timestamping" its generated binaries, so that they become more "git-friendly" ?

On Sun, Sep 29, 2019 at 11:15:43AM +0000, Ecstatic Coder via Digitalmars-d wrote:
> Every time I compile the same code with DMD, I get a slightly different ".exe" file on Windows.
> 
> fc /b basil.exe basil_old_1.exe
> 00000118: 9F 55
> 00000119: 8C 89
> 00156554: 9F 55
> 00156555: 8C 89
> 
> fc /b basil.exe basil_old_2.exe
> 00000118: 9F 1B
> 00000119: 8C 8A
> 00156554: 9F 1B
> 00156555: 8C 8A
> 
> This problem is D specific, as for instance Go will generate the same executable each time.
> 
> So before I implement a tool for this, is there an easy way to prevent DMD from "timestamping" its generated binaries, so that they become more "git-friendly" ?

Seems this is Windows-specific; I can't reproduce this on my Linux box. Which leads me to think this isn't a dmd problem; it may be the linker that's inserting the timestamp. Which linker is being used? Perhaps an approprate option passed to the linker is what you need. You can pass options to the linker with -L... (on Windows it might be /L..., not 100% sure).


T

-- 
Give a man a fish, and he eats once. Teach a man to fish, and he will sit forever.

On Sunday, 29 September 2019 at 11:15:43 UTC, Ecstatic Coder wrote:
> Every time I compile the same code with DMD, I get a slightly different ".exe" file on Windows.
>
> fc /b basil.exe basil_old_1.exe
> 00000118: 9F 55
> 00000119: 8C 89
> 00156554: 9F 55
> 00156555: 8C 89
>
> fc /b basil.exe basil_old_2.exe
> 00000118: 9F 1B
> 00000119: 8C 8A
> 00156554: 9F 1B
> 00156555: 8C 8A
>
> This problem is D specific, as for instance Go will generate the same executable each time.
>
> So before I implement a tool for this, is there an easy way to prevent DMD from "timestamping" its generated binaries, so that they become more "git-friendly" ?

Since 2.077 dmd builds should be reproducible https://dlang.org/changelog/2.077.0.html#reproducible_builds

Kind regards
Andre

On Sunday, 29 September 2019 at 12:30:46 UTC, H. S. Teoh wrote:
> On Sun, Sep 29, 2019 at 11:15:43AM +0000, Ecstatic Coder via Digitalmars-d wrote:
>> Every time I compile the same code with DMD, I get a slightly different ".exe" file on Windows.
>> 
>> fc /b basil.exe basil_old_1.exe
>> 00000118: 9F 55
>> 00000119: 8C 89
>> 00156554: 9F 55
>> 00156555: 8C 89
>> 
>> fc /b basil.exe basil_old_2.exe
>> 00000118: 9F 1B
>> 00000119: 8C 8A
>> 00156554: 9F 1B
>> 00156555: 8C 8A
>> 
>> This problem is D specific, as for instance Go will generate the same executable each time.
>> 
>> So before I implement a tool for this, is there an easy way to prevent DMD from "timestamping" its generated binaries, so that they become more "git-friendly" ?
>
> Seems this is Windows-specific; I can't reproduce this on my Linux box. Which leads me to think this isn't a dmd problem; it may be the linker that's inserting the timestamp. Which linker is being used? Perhaps an approprate option passed to the linker is what you need. You can pass options to the linker with -L... (on Windows it might be /L..., not 100% sure).
>
>
> T

Ah, then I guess it's probably because I'm using the MinGW option when installing the DMD compiler, as unfortunately it's the only "lean" option that remains :(

OK, I'll try deinstalling DMD, and then reinstalling it with the "huge" option (=VS)...

Thanks for the hint :)

On Sunday, 29 September 2019 at 13:06:37 UTC, Ecstatic Coder wrote:
> Ah, then I guess it's probably because I'm using the MinGW option when installing the DMD compiler, as unfortunately it's the only "lean" option that remains :(

why doesn't the zip work for you? it doesn't need VS either and the recent versions even do 64 bit with its built in linker

On Sunday, 29 September 2019 at 13:12:53 UTC, Adam D. Ruppe wrote:
> On Sunday, 29 September 2019 at 13:06:37 UTC, Ecstatic Coder wrote:
>> Ah, then I guess it's probably because I'm using the MinGW option when installing the DMD compiler, as unfortunately it's the only "lean" option that remains :(
>
> why doesn't the zip work for you? it doesn't need VS either and the recent versions even do 64 bit with its built in linker

Ah indeed it sounds like the perfect version to me. Agains it's VERY infortunate that this "leanest" version isn't installed by default.

I've been asked several times to add the executable files on the Github repository of my open source tools because their users (including me) get angry when they see that the DMD installer is trying to force them to install VS just to compile a tiny tool like Pendown, Genesis or Cibyl.

IMO that's a very bad decision as it prevents adoption, not only for my humble tools, but also for the D language itself...

On Sunday, 29 September 2019 at 11:15:43 UTC, Ecstatic Coder wrote:
> Every time I compile the same code with DMD, I get a slightly different ".exe" file on Windows.
>
> So before I implement a tool for this, is there an easy way to prevent DMD from "timestamping" its generated binaries, so that they become more "git-friendly" ?

Using the mingw64 setup you have two options, from LLVM linker usage help:
(lld-link --help)

/Brepro               Use a hash of the executable as the PE header timestamp
/timestamp:<value>    Specify the PE header timestamp

The first emulates a Visual Studio linker undocumented option. If you change to the VS config this should work too.
The second uses a classic C/Unix timestamp value (time() function).

Also, make sure to NOT USE optlink linker by using -m32mscoff -m64 respectively.

Example:

dmd test.d -m64 -L/Brepro      // or -L/timestamp:0

On Sunday, 29 September 2019 at 23:14:10 UTC, Boris Carvajal wrote:
> On Sunday, 29 September 2019 at 11:15:43 UTC, Ecstatic Coder wrote:
>> Every time I compile the same code with DMD, I get a slightly different ".exe" file on Windows.
>>
>> So before I implement a tool for this, is there an easy way to prevent DMD from "timestamping" its generated binaries, so that they become more "git-friendly" ?
>
> Using the mingw64 setup you have two options, from LLVM linker usage help:
> (lld-link --help)
>
> /Brepro               Use a hash of the executable as the PE header timestamp
> /timestamp:<value>    Specify the PE header timestamp
>
> The first emulates a Visual Studio linker undocumented option. If you change to the VS config this should work too.
> The second uses a classic C/Unix timestamp value (time() function).
>
> Also, make sure to NOT USE optlink linker by using -m32mscoff -m64 respectively.
>
> Example:
>
> dmd test.d -m64 -L/Brepro      // or -L/timestamp:0

Exactly the compiler option I was looking for :)

Thanks a lot to you, and also to the other nice members of the D community who have taken the time to answer my question. Much appreciatd!