digitalmars.D - How to prevent DMD from changing the executable files at each
- Ecstatic Coder (17/17) Sep 29 2019 Every time I compile the same code with DMD, I get a slightly
- H. S. Teoh (10/31) Sep 29 2019 Seems this is Windows-specific; I can't reproduce this on my Linux box.
- Ecstatic Coder (7/37) Sep 29 2019 Ah, then I guess it's probably because I'm using the MinGW option
- Adam D. Ruppe (4/7) Sep 29 2019 why doesn't the zip work for you? it doesn't need VS either and
- Ecstatic Coder (11/18) Sep 29 2019 Ah indeed it sounds like the perfect version to me. Agains it's
- Andre Pany (6/23) Sep 29 2019 Since 2.077 dmd builds should be reproducible
- Boris Carvajal (16/21) Sep 29 2019 Using the mingw64 setup you have two options, from LLVM linker
- Ecstatic Coder (6/28) Sep 29 2019 Exactly the compiler option I was looking for :)
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" ?
Sep 29 2019
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.
Sep 29 2019
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: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 :)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
Sep 29 2019
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
Sep 29 2019
Ecstatic Coder <ecstatic.coder gmail.com> 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 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...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
Sep 29 2019
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
Sep 29 2019
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
Sep 29 2019
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: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!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
Sep 29 2019