In `src/dmd/link.d` the section `version (Windows)` assumes MSVC is used, causing the `link` to be used when building MinGW-w64. When doing this in MSYS2 shell it will call the `link` command, which makes file links (part of GNU coreutils).
The `version (Posix)` won't work for MinGW-w64 since it uses pipes and forks to run the linker, which won't work on Windows.
So I think a `version (MinGW)` is needed (before `version (Windows)` since that will match too) that uses GCC linking, called in a Windows way (`executecmd()`) and with the right flags for MinGW (which is probably (mostly) the same as Posix.
Comment #1 by kinke — 2022-05-15T19:08:09Z
That's just one detail of lacking MinGW support (of both DMD and LDC). The compiler would also need to predefine version `MinGW` for druntime/Phobos (there's some support in the libraries, for GDC). C++ mangling in the frontend would need to switch from MSVC to Itanium. Debuginfos would need to switch from CodeView to DWARF format. Static libs (.a) are probably different than the MS ones (.lib). Etc. etc.
Comment #2 by brecht — 2022-05-15T20:25:41Z
FYI:
In my environment I am able to build druntime and libphobos
It's getting GDC to build that I'm really having a hard time with.
Mangling, library format, etc are very similar to other platforms that use COFF format.
Is there any work being done on adding MinGW support?
Comment #3 by brecht — 2022-09-11T17:59:01Z
Looks like dmd 2.100.2 still has no support for using gcc/binutils in src/dmd/link.d
Using LINKCMD=ld.exe doesn't work as command line arguments starting with a slash won't work (e.g. "/OUT:").
Is there any hope we can see support for gcc/binutils on Windows in the near future?
Comment #4 by robert.schadek — 2024-12-13T19:22:45Z