www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - X86_mscoff / x86_64 as default for dub projects (windows)

reply Andre Pany <andre s-e-a-p.de> writes:
Hi,

This is mostly interesting for windows developers. What is your 
opinion of switching to architecture x86_mscoff or x86_64 as 
default on windows?

To be pretty clear, you still can compile to x86 OMF by setting 
the default architecture either in settings.json or as command 
line argument. The proposal is just to set another default.

This is now possible as DMD and LDC comes with lld and the needed 
libraries.

Kind regards
Andre
Dec 06 2018
next sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Thursday, 6 December 2018 at 17:58:17 UTC, Andre Pany wrote:
 Hi,

 This is mostly interesting for windows developers. What is your 
 opinion of switching to architecture x86_mscoff or x86_64 as 
 default on windows?
I am om favour of this. It would help prevent people running into optlink problems such as this one: https://github.com/MartinNowak/scod/issues/4 Bastiaan.
Dec 06 2018
prev sibling next sibling parent kinke <noone nowhere.com> writes:
On Thursday, 6 December 2018 at 17:58:17 UTC, Andre Pany wrote:
 Hi,

 This is mostly interesting for windows developers. What is your 
 opinion of switching to architecture x86_mscoff or x86_64 as 
 default on windows?

 To be pretty clear, you still can compile to x86 OMF by setting 
 the default architecture either in settings.json or as command 
 line argument. The proposal is just to set another default.
I also think this is long overdue - but I wouldn't change dub's defaults, but DMD's instead (something like `-m32` on Windows meaning `-m32mscoff`, and a new `-m32omf` switch). It's a breaking change, but definitely worth it IMO. Besides optlink bugs and limitations, and the executable unfortunately being named `link.exe` and so conflicting with the MS one (and people running into problems when using LDC, depending on their PATH), I see the primary drawback in that probably > 99.9% of 3rd-party libraries out there are in COFF format (I haven't heard of that old OMF format from DOS times before playing with DMD).
Dec 06 2018
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, December 6, 2018 10:58:17 AM MST Andre Pany via Digitalmars-d 
wrote:
 Hi,

 This is mostly interesting for windows developers. What is your
 opinion of switching to architecture x86_mscoff or x86_64 as
 default on windows?

 To be pretty clear, you still can compile to x86 OMF by setting
 the default architecture either in settings.json or as command
 line argument. The proposal is just to set another default.

 This is now possible as DMD and LDC comes with lld and the needed
 libraries.
I'm inclined to argue that it's a bad idea given that it's not dmd's default. It risks being very confusing, and anyone who actually cares to make the change can easily set their dub configuration accordingly. - Jonathan M Davis
Dec 06 2018
prev sibling next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Thursday, 6 December 2018 at 17:58:17 UTC, Andre Pany wrote:
 Hi,

 This is mostly interesting for windows developers. What is your 
 opinion of switching to architecture x86_mscoff or x86_64 as 
 default on windows?

 To be pretty clear, you still can compile to x86 OMF by setting 
 the default architecture either in settings.json or as command 
 line argument. The proposal is just to set another default.

 This is now possible as DMD and LDC comes with lld and the 
 needed libraries.

 Kind regards
 Andre
I'd wish this too (i also wish DWARF info in mscoff). Unfortunately last time i tried to built DCD using -m64 (and MINGW stuff + LLD) the resulting PE crashed, so maybe there are problems to fix before switching.
Dec 06 2018
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 07/12/2018 11:50 AM, Basile B. wrote:
 On Thursday, 6 December 2018 at 17:58:17 UTC, Andre Pany wrote:
 Hi,

 This is mostly interesting for windows developers. What is your 
 opinion of switching to architecture x86_mscoff or x86_64 as default 
 on windows?

 To be pretty clear, you still can compile to x86 OMF by setting the 
 default architecture either in settings.json or as command line 
 argument. The proposal is just to set another default.

 This is now possible as DMD and LDC comes with lld and the needed 
 libraries.

 Kind regards
 Andre
I'd  wish this too (i also wish DWARF info in mscoff). Unfortunately last time i tried to built DCD using -m64 (and MINGW stuff + LLD) the resulting PE crashed, so maybe there are problems to fix before switching.
Agreed we should hold off until mingw + lld stuff gain more maturity. Then we can swap over fully with minimal pain.
Dec 06 2018
parent Andre Pany <andre s-e-a-p.de> writes:
On Friday, 7 December 2018 at 06:52:41 UTC, rikki cattermole 
wrote:
 On 07/12/2018 11:50 AM, Basile B. wrote:
 
 I'd  wish this too (i also wish DWARF info in mscoff). 
 Unfortunately last time i tried to built DCD using -m64 (and 
 MINGW stuff + LLD) the resulting PE crashed, so maybe there 
 are problems to fix before switching.
Agreed we should hold off until mingw + lld stuff gain more maturity. Then we can swap over fully with minimal pain.
Thanks a lot for the opinions. Maybe we could check that e.g. all dub packages compiles fine (and unittests succeeds) with LLD to check the maturity. When we reached that level we can switch the default architecture. I also like the idea to switch the architecture in DMD itself to avoid surprises. And I really like to have a 64 bit DMD executable. Fortunately it is created by the nightly builds, but having it as release download would be really great. Kind regards André
Dec 07 2018
prev sibling parent reply Rubn <where is.this> writes:
On Thursday, 6 December 2018 at 22:50:25 UTC, Basile B. wrote:
 On Thursday, 6 December 2018 at 17:58:17 UTC, Andre Pany wrote:
 Hi,

 This is mostly interesting for windows developers. What is 
 your opinion of switching to architecture x86_mscoff or x86_64 
 as default on windows?

 To be pretty clear, you still can compile to x86 OMF by 
 setting the default architecture either in settings.json or as 
 command line argument. The proposal is just to set another 
 default.

 This is now possible as DMD and LDC comes with lld and the 
 needed libraries.

 Kind regards
 Andre
I'd wish this too (i also wish DWARF info in mscoff). Unfortunately last time i tried to built DCD using -m64 (and MINGW stuff + LLD) the resulting PE crashed, so maybe there are problems to fix before switching.
This is part of the problem, in that there are more tests run on Linux than Windows. DMD doesn't even compile it self on Windows to test. It does for linux though. Also some of the community projects are all compiled and tested on linux but not windows. That's the state it is in, the only tests that are run are the most basic ones. Can't expect DMD on Windows to be stable at all, if ever that's the way it goes though I guess. No one seems to care or thinks running tests on linux only is good enough for windows.
Dec 07 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, December 7, 2018 3:15:30 PM MST Rubn via Digitalmars-d wrote:
 On Thursday, 6 December 2018 at 22:50:25 UTC, Basile B. wrote:
 On Thursday, 6 December 2018 at 17:58:17 UTC, Andre Pany wrote:
 Hi,

 This is mostly interesting for windows developers. What is
 your opinion of switching to architecture x86_mscoff or x86_64
 as default on windows?

 To be pretty clear, you still can compile to x86 OMF by
 setting the default architecture either in settings.json or as
 command line argument. The proposal is just to set another
 default.

 This is now possible as DMD and LDC comes with lld and the
 needed libraries.

 Kind regards
 Andre
I'd wish this too (i also wish DWARF info in mscoff). Unfortunately last time i tried to built DCD using -m64 (and MINGW stuff + LLD) the resulting PE crashed, so maybe there are problems to fix before switching.
This is part of the problem, in that there are more tests run on Linux than Windows. DMD doesn't even compile it self on Windows to test. It does for linux though. Also some of the community projects are all compiled and tested on linux but not windows. That's the state it is in, the only tests that are run are the most basic ones. Can't expect DMD on Windows to be stable at all, if ever that's the way it goes though I guess. No one seems to care or thinks running tests on linux only is good enough for windows.
The entire test suite for druntime, Phobos, and dmd has to pass on all supported platforms on the auto-tester: https://auto-tester.puremagic.com/ Windows is not exempt from that. So, unless there are a bunch of tests in the test suite which are needlessly platform-specific, Windows is getting tested just as much as Linux is. Where do you get the idea that it's not? - Jonathan M Davis
Dec 07 2018
parent reply Rubn <where is.this> writes:
On Saturday, 8 December 2018 at 02:08:14 UTC, Jonathan M Davis 
wrote:
 On Friday, December 7, 2018 3:15:30 PM MST Rubn via 
 Digitalmars-d wrote:
 On Thursday, 6 December 2018 at 22:50:25 UTC, Basile B. wrote:
 On Thursday, 6 December 2018 at 17:58:17 UTC, Andre Pany 
 wrote:
 Hi,

 This is mostly interesting for windows developers. What is 
 your opinion of switching to architecture x86_mscoff or 
 x86_64 as default on windows?

 To be pretty clear, you still can compile to x86 OMF by 
 setting the default architecture either in settings.json or 
 as command line argument. The proposal is just to set 
 another default.

 This is now possible as DMD and LDC comes with lld and the 
 needed libraries.

 Kind regards
 Andre
I'd wish this too (i also wish DWARF info in mscoff). Unfortunately last time i tried to built DCD using -m64 (and MINGW stuff + LLD) the resulting PE crashed, so maybe there are problems to fix before switching.
This is part of the problem, in that there are more tests run on Linux than Windows. DMD doesn't even compile it self on Windows to test. It does for linux though. Also some of the community projects are all compiled and tested on linux but not windows. That's the state it is in, the only tests that are run are the most basic ones. Can't expect DMD on Windows to be stable at all, if ever that's the way it goes though I guess. No one seems to care or thinks running tests on linux only is good enough for windows.
The entire test suite for druntime, Phobos, and dmd has to pass on all supported platforms on the auto-tester: https://auto-tester.puremagic.com/ Windows is not exempt from that. So, unless there are a bunch of tests in the test suite which are needlessly platform-specific, Windows is getting tested just as much as Linux is. Where do you get the idea that it's not? - Jonathan M Davis
https://ci.dlang.io/blue/organizations/jenkins/dlang-org%2Fdmd/detail/PR-8519/3/pipeline I guess that's just another dead project, so I guess no platform is getting those tests anymore. Too bad, I guess that's another story for D, unless they moved to something else. What you linked are just those basic tests, those tests don't do anything complicated like building DMD itself with the newly created DMD and running the tests for both to ensure a correct binary is produced.
Dec 07 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, December 7, 2018 8:09:37 PM MST Rubn via Digitalmars-d wrote:
 On Saturday, 8 December 2018 at 02:08:14 UTC, Jonathan M Davis
 wrote:
 On Friday, December 7, 2018 3:15:30 PM MST Rubn via
 This is part of the problem, in that there are more tests run
 on Linux than Windows. DMD doesn't even compile it self on
 Windows to test. It does for linux though. Also some of the
 community projects are all compiled and tested on linux but
 not windows. That's the state it is in, the only tests that
 are run are the most basic ones. Can't expect DMD on Windows
 to be stable at all, if ever that's the way it goes though I
 guess. No one seems to care or thinks running tests on linux
 only is good enough for windows.
The entire test suite for druntime, Phobos, and dmd has to pass on all supported platforms on the auto-tester: https://auto-tester.puremagic.com/ Windows is not exempt from that. So, unless there are a bunch of tests in the test suite which are needlessly platform-specific, Windows is getting tested just as much as Linux is. Where do you get the idea that it's not? - Jonathan M Davis
https://ci.dlang.io/blue/organizations/jenkins/dlang-org%2Fdmd/detail/PR-8 519/3/pipeline I guess that's just another dead project, so I guess no platform is getting those tests anymore. Too bad, I guess that's another story for D, unless they moved to something else.
I think that they moved those tests to buildkite, but I don't know what the exact situation with that is right now. While the main auto-tester has been the same for ages, they keep changing what they're doing with the other tests. But I believe that the tests for each project are run using travis and depend on how each project set that up, so which which platforms they test is going to vary from project to project. And I don't think that that includes Windows at all, because that would require something like appveyor. So, the testing of projects beyond dmd and the standard library is only on *nix systems AFAIK, but dmd itself and the standard library are definitely tested on all of the platforms that dmd supports.
 What you linked are just those basic tests, those tests don't do
 anything complicated like building DMD itself with the newly
 created DMD and running the tests for both to ensure a correct
 binary is produced.
The new compiler is built and used to run the druntime and Phobos test suites. Then it's used with the newly built druntime and Phobos to run the dmd test suite. So, the new dmd binary is definitely being tested, but no, the newly built dmd isn't then used to build dmd yet again as part of those tests. - Jonathan M Davis
Dec 07 2018
parent Seb <seb wilzba.ch> writes:
On Saturday, 8 December 2018 at 03:25:46 UTC, Jonathan M Davis 
wrote:
 On Friday, December 7, 2018 8:09:37 PM MST Rubn via 
 Digitalmars-d wrote:
 On Saturday, 8 December 2018 at 02:08:14 UTC, Jonathan M Davis 
 wrote:
 On Friday, December 7, 2018 3:15:30 PM MST Rubn via
 This is part of the problem, in that there are more tests 
 run on Linux than Windows. DMD doesn't even compile it self 
 on Windows to test. It does for linux though. Also some of 
 the community projects are all compiled and tested on linux 
 but not windows. That's the state it is in, the only tests 
 that are run are the most basic ones. Can't expect DMD on 
 Windows to be stable at all, if ever that's the way it goes 
 though I guess. No one seems to care or thinks running 
 tests on linux only is good enough for windows.
The entire test suite for druntime, Phobos, and dmd has to pass on all supported platforms on the auto-tester: https://auto-tester.puremagic.com/ Windows is not exempt from that. So, unless there are a bunch of tests in the test suite which are needlessly platform-specific, Windows is getting tested just as much as Linux is. Where do you get the idea that it's not? - Jonathan M Davis
https://ci.dlang.io/blue/organizations/jenkins/dlang-org%2Fdmd/detail/PR-8 519/3/pipeline I guess that's just another dead project, so I guess no platform is getting those tests anymore. Too bad, I guess that's another story for D, unless they moved to something else.
I think that they moved those tests to buildkite, but I don't know what the exact situation with that is right now.
That's correct. Buildkite is a lot easier to work with then Jenkins. Here's the overview page for the dlang pipelines: https://buildkite.com/dlang
 While the main auto-tester has been the same for ages, they 
 keep changing what they're doing with the other tests.
Yeah, we use too many resources for any of the free CIs to handle it. Though it looks like our current move to Buildkite was a good one and we can unify a few services under it - though as long as no one actually has Windows or OSX machines, that will be hard.
 But I believe that the tests for each project are run using 
 travis and depend on how each project set that up, so which 
 which platforms they test is going to vary from project to 
 project. And I don't think that that includes Windows at all, 
 because that would require something like appveyor.
We use Appveyor for DMD and druntime, though we keep running into the limit there too.
 So, the testing of projects beyond dmd and the standard library 
 is only on *nix systems AFAIK, but dmd itself and the standard 
 library are definitely tested on all of the platforms that dmd 
 supports.
Yup, as mentioned currently we just don't have any Windows nor OSX machines to hook up with Buildkite.
 What you linked are just those basic tests, those tests don't 
 do anything complicated like building DMD itself with the 
 newly created DMD and running the tests for both to ensure a 
 correct binary is produced.
The new compiler is built and used to run the druntime and Phobos test suites. Then it's used with the newly built druntime and Phobos to run the dmd test suite. So, the new dmd binary is definitely being tested, but no, the newly built dmd isn't then used to build dmd yet again as part of those tests.
This bootstrapping is tested (though not on the Auto-Tester). That's e.g. what we do with SemaphoreCI.
Dec 19 2018
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 6 December 2018 at 17:58:17 UTC, Andre Pany wrote:
 Hi,

 This is mostly interesting for windows developers. What is your 
 opinion of switching to architecture x86_mscoff or x86_64 as 
 default on windows?
The problem is that DMD -m32 always works, else you need a _correct_ install of VS to build the other archs and it's not always _that_ easy to have when you did things in an order that wasn't exactly the one of the installer. please, no.
Dec 07 2018
parent reply Andre Pany <andre s-e-a-p.de> writes:
On Friday, 7 December 2018 at 13:11:37 UTC, Guillaume Piolat 
wrote:
 On Thursday, 6 December 2018 at 17:58:17 UTC, Andre Pany wrote:
 Hi,

 This is mostly interesting for windows developers. What is 
 your opinion of switching to architecture x86_mscoff or x86_64 
 as default on windows?
The problem is that DMD -m32 always works, else you need a _correct_ install of VS to build the other archs and it's not always _that_ easy to have when you did things in an order that wasn't exactly the one of the installer. please, no.
Visual studio is no longer needed as lld and x86mscoff/x86_64 libraries now included in dmd and LDC:) We just need to get it mature. Kind regards Andre
Dec 07 2018
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Friday, 7 December 2018 at 13:23:54 UTC, Andre Pany wrote:
 Visual studio is no longer needed as lld and x86mscoff/x86_64 
 libraries now included in dmd and LDC:)

 We just need to get it mature.

 Kind regards
 Andre
Is it any faster than OPTLINK?
Dec 08 2018
next sibling parent Andre Pany <andre s-e-a-p.de> writes:
On Saturday, 8 December 2018 at 15:04:12 UTC, Guillaume Piolat 
wrote:
 On Friday, 7 December 2018 at 13:23:54 UTC, Andre Pany wrote:
 Visual studio is no longer needed as lld and x86mscoff/x86_64 
 libraries now included in dmd and LDC:)

 We just need to get it mature.

 Kind regards
 Andre
Is it any faster than OPTLINK?
LLD is advertised as a very fast linker. Whether that is true I can't say, I didn't measure it. But there should be also other benefits: -it is actively developed by llvm community - you do not have to convert static libs from coff to omf (e.g. SQLite,...) Current situation is, you can't create documentation in format ddox because of an Optlink bug. This bug is known for a very long time. Kind regards Andre
Dec 08 2018
prev sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Saturday, 8 December 2018 at 15:04:12 UTC, Guillaume Piolat 
wrote:
 On Friday, 7 December 2018 at 13:23:54 UTC, Andre Pany wrote:
 Visual studio is no longer needed as lld and x86mscoff/x86_64 
 libraries now included in dmd and LDC:)

 We just need to get it mature.

 Kind regards
 Andre
Is it any faster than OPTLINK?
I had some tries. LLD link is very fast in my applications. It feels even noticeable faster than OPTLINK. But also I facing some maturity issues. - While trying to run dub test in combination with dependency d-unit and a module command.d containing an std.datetime import there is always an linker error: Native PDB Error: The entry already exists. The specified module already exists I have a reduced test case (dustmite is great!) and will file an issue - From time to time there is a spurious linker error: Error: module `NOLOGO` is in file '\NOLOGO.d' which cannot be read I don't know how to reproduce this error but it disappears on next try. Kind regards André
Dec 19 2018
parent reply Andre Pany <andre s-e-a-p.de> writes:
On Wednesday, 19 December 2018 at 11:32:58 UTC, Andre Pany wrote:
 On Saturday, 8 December 2018 at 15:04:12 UTC, Guillaume Piolat 
 wrote:
 On Friday, 7 December 2018 at 13:23:54 UTC, Andre Pany wrote:
 Visual studio is no longer needed as lld and x86mscoff/x86_64 
 libraries now included in dmd and LDC:)

 We just need to get it mature.

 Kind regards
 Andre
Is it any faster than OPTLINK?
I had some tries. LLD link is very fast in my applications. It feels even noticeable faster than OPTLINK. But also I facing some maturity issues. - While trying to run dub test in combination with dependency d-unit and a module command.d containing an std.datetime import there is always an linker error: Native PDB Error: The entry already exists. The specified module already exists I have a reduced test case (dustmite is great!) and will file an issue - From time to time there is a spurious linker error: Error: module `NOLOGO` is in file '\NOLOGO.d' which cannot be read I don't know how to reproduce this error but it disappears on next try. Kind regards André
As pointed out by Kinke in issue 19503, dmd ships with an old lld-link version (v5.0.1). Replacing it with v7.0 (already shipped with recent LDC) solves the Native PDB Error. (I have to update the issue https://issues.dlang.org/show_bug.cgi?id=19503) The spurious NOLOGO problem still occurs on every 3 or 4 try for exactly the same dmd linker command (generated by dub). Kind regards André
Dec 20 2018
parent Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 20 December 2018 at 09:24:33 UTC, Andre Pany wrote:
 As pointed out by Kinke in issue 19503, dmd ships with an old 
 lld-link version (v5.0.1).
 Replacing it with v7.0 (already shipped with recent LDC) solves
 the Native PDB Error.

 (I have to update the issue 
 https://issues.dlang.org/show_bug.cgi?id=19503)

 The spurious NOLOGO problem still occurs on every 3 or 4 try 
 for exactly
 the same dmd linker command (generated by dub).

 Kind regards
 André
It would be a cool thing to change the default if D_SIMD was defined for -m32mscoff. Was it a OPTLINK problem that D_SIMD isn't there for 32-bit Windows target?
Dec 25 2018
prev sibling next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Thursday, 6 December 2018 at 17:58:17 UTC, Andre Pany wrote:
 This is mostly interesting for windows developers. What is your 
 opinion of switching to architecture x86_mscoff or x86_64 as 
 default on windows?
My biggest gripe is this confusing matrix of compiler flags: default -m32 -m32mscoff -m64 dmd OMF OMF COFF-32 COFF-64 ldc COFF-64 COFF-32 Error COFF-64 The same applies to dub's --arch flag. Currently, the default works out of the box and I don't want to change that. I also don't like the idea of changing semantics and break code / expectations of users that way. Maybe we can make the current flags for dub/the compilers undocumented and define new, consistent flags.
Dec 07 2018
parent kinke <noone nowhere.com> writes:
On Friday, 7 December 2018 at 13:58:12 UTC, Dennis wrote:
 My biggest gripe is this confusing matrix of compiler flags:

       default  -m32     -m32mscoff  -m64
 dmd   OMF      OMF      COFF-32     COFF-64
 ldc   COFF-64  COFF-32  Error       COFF-64
Some corrections for LDC: * The default depends on the host. If you're using a 64-bit LDC executable, it defaults to producing 64-bit code. * `-m32mscoff` is supported by LDMD, which is the DMD-compatible wrapper (and simply translates it to `-m32` for the LDC executable).
Dec 07 2018
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Thursday, 6 December 2018 at 17:58:17 UTC, Andre Pany wrote:
 Hi,

 This is mostly interesting for windows developers. What is your 
 opinion of switching to architecture x86_mscoff or x86_64 as 
 default on windows?

 To be pretty clear, you still can compile to x86 OMF by setting 
 the default architecture either in settings.json or as command 
 line argument. The proposal is just to set another default.

 This is now possible as DMD and LDC comes with lld and the 
 needed libraries.

 Kind regards
 Andre
To me, it's obvious that the default on Windows 64-bit (i.e. "Windows" for 99.9% of the population) should be x86_64.
Dec 19 2018
parent Andre Pany <andre s-e-a-p.de> writes:
On Wednesday, 19 December 2018 at 13:11:19 UTC, Atila Neves wrote:
 On Thursday, 6 December 2018 at 17:58:17 UTC, Andre Pany wrote:
 Hi,

 This is mostly interesting for windows developers. What is 
 your opinion of switching to architecture x86_mscoff or x86_64 
 as default on windows?

 To be pretty clear, you still can compile to x86 OMF by 
 setting the default architecture either in settings.json or as 
 command line argument. The proposal is just to set another 
 default.

 This is now possible as DMD and LDC comes with lld and the 
 needed libraries.

 Kind regards
 Andre
To me, it's obvious that the default on Windows 64-bit (i.e. "Windows" for 99.9% of the population) should be x86_64.
I propose a smooth transition in 3 steps: - 64 bit version of DMD should default to x86_64 instead of x86 (Optlink). I will check whether I am able to create the pr. - an additional Windows package should be created for each release containing the 64 bit dmd version. This package should be clearly marked as experimental while the current Windows package is marked as stable. - in some years, if 64 bit dmd and lld is proofed to be stable, either both packages can be combined into 1 or we can leave both packages but remove the experimental tag. Kind regards Andre
Dec 19 2018