Thread overview
MinGW 6.0.0 libraries for DMD
Apr 14, 2019
Seb
Apr 14, 2019
jmh530
Apr 15, 2019
Basile B.
Apr 15, 2019
Basile B.
Apr 15, 2019
kinke
Apr 15, 2019
Andre Pany
Apr 15, 2019
Dejan Lekic
April 14, 2019
Hi all,

so I just revitalized the half-dead PR from kinke [1] which upgrades DMD's MinGW libraries to MinGW-64 6.0.0.

The bundle is now available at [2] and it would be awesome if the people actually interested in this could give it a quick test:

1) Download the built MinGW libaries from [2]
2) Replace them with dmd2/windows/lib64/mingw and/or dmd2/windows/lib32mscoff in your DMD Windows installation
3) Test whether everything is still working

Ideally we could get this in before the upcoming 2.086.0 beta (about to branch off in two days), s.t. the Windows folk who were running into problems with the older MinGW 5 libraries can use this officially starting from May.

The PR to switch the installer/release to use MinGW 6.0.0 is available at [3].

Disclaimer: I don't use Windows, but I do hear that people complain about it too often.

Cheers,

Seb

[1] https://github.com/dlang/installer/pull/346
[2] http://downloads.dlang.org/other/mingw-libs-6.0.0.zip
[3] https://github.com/dlang/installer/pull/377
April 14, 2019
On Sunday, 14 April 2019 at 08:19:01 UTC, Seb wrote:
> Hi all,
>
> so I just revitalized the half-dead PR from kinke [1] which upgrades DMD's MinGW libraries to MinGW-64 6.0.0.
>
> [snip]

I just tried one compiling one file with -m64 and -m32mscoff and didn't have any issues, if that helps.
April 15, 2019
On Sunday, 14 April 2019 at 08:19:01 UTC, Seb wrote:
> Hi all,
>
> so I just revitalized the half-dead PR from kinke [1] which upgrades DMD's MinGW libraries to MinGW-64 6.0.0.
>
> The bundle is now available at [2] and it would be awesome if the people actually interested in this could give it a quick test:
>
> 1) Download the built MinGW libaries from [2]
> 2) Replace them with dmd2/windows/lib64/mingw and/or dmd2/windows/lib32mscoff in your DMD Windows installation
> 3) Test whether everything is still working

This is not ready. When building DCD with build.bat with MFLAGS set to -m64 I get this linker error:

  lld-link.exe: error: /alternatename: conflicts: fileno=_fileno
  Error: linker exited with status 1

This error doesn't occur with the older libraries.
April 15, 2019
On Monday, 15 April 2019 at 11:22:04 UTC, Basile B. wrote:
> On Sunday, 14 April 2019 at 08:19:01 UTC, Seb wrote:
>> Hi all,
>>
>> so I just revitalized the half-dead PR from kinke [1] which upgrades DMD's MinGW libraries to MinGW-64 6.0.0.
>>
>> The bundle is now available at [2] and it would be awesome if the people actually interested in this could give it a quick test:
>>
>> 1) Download the built MinGW libaries from [2]
>> 2) Replace them with dmd2/windows/lib64/mingw and/or dmd2/windows/lib32mscoff in your DMD Windows installation
>> 3) Test whether everything is still working
>
> This is not ready. When building DCD with build.bat with MFLAGS set to -m64 I get this linker error:
>
>   lld-link.exe: error: /alternatename: conflicts: fileno=_fileno
>   Error: linker exited with status 1
>
> This error doesn't occur with the older libraries.

There's a very simple test case, don't forget the -m64, that is:

  void main()
  {
      import core.stdc.stdio;
      auto a = fileno(stdin);
  }

It must compile. It's probably just a druntime issue.
April 15, 2019
On Sunday, 14 April 2019 at 08:19:01 UTC, Seb wrote:
> Hi all,
>
> so I just revitalized the half-dead PR from kinke [1] which upgrades DMD's MinGW libraries to MinGW-64 6.0.0.
>

Brilliant! Thanks!

I am rarely on Windows, but when I do use it, I almost exclusively use MSYS2, and may need DMD to build some tiny programs there...

I will definitely give it a try next time I am on Windows.
Cheers!
April 15, 2019
On Monday, 15 April 2019 at 12:02:03 UTC, Basile B. wrote:
> On Monday, 15 April 2019 at 11:22:04 UTC, Basile B. wrote:
>> This is not ready. When building DCD with build.bat with MFLAGS set to -m64 I get this linker error:
>>
>>   lld-link.exe: error: /alternatename: conflicts: fileno=_fileno
>>   Error: linker exited with status 1
>>
>> This error doesn't occur with the older libraries.

Thanks for the feedback. There are 'weak aliases' in https://github.com/dlang/druntime/blob/8fd52019826259dc92ab712f4b37a3f0ea4d8265/src/rt/msvc.c which collide with the ones defined in the MinGW-based libs (and those latter are likely not to be 100% correct for DMD's default VS2010 libs, as they have been derived from the VS 2015 libs for LDC).

These new libs are the same libs included by LDC since v1.13; it's not a problem there because almost all of these aliases in LDC's druntime are disabled (not needed since VS 2015).

So there are 2 ways of fixing this - either extracting the aliases from the VS2010 libs for DMD, or making DMD switch to the VS2015 libs (Universal CRT...) by default, just like LDC. I obviously prefer the latter, not just for consistency across DMD and LDC and hence reduced maintenance effort, but also because there have been major improvements wrt. C99 support in more recent MS libraries.
April 15, 2019
On Monday, 15 April 2019 at 21:54:05 UTC, kinke wrote:
> On Monday, 15 April 2019 at 12:02:03 UTC, Basile B. wrote:
>>> [...]
>
> Thanks for the feedback. There are 'weak aliases' in https://github.com/dlang/druntime/blob/8fd52019826259dc92ab712f4b37a3f0ea4d8265/src/rt/msvc.c which collide with the ones defined in the MinGW-based libs (and those latter are likely not to be 100% correct for DMD's default VS2010 libs, as they have been derived from the VS 2015 libs for LDC).
>
> [...]

I am not 100% sure but does switching to VS2015 also solves this issue? https://issues.dlang.org/show_bug.cgi?id=19760
If I understood it correct ucrt is pre installed on windows 10.

Kind regards
Andre