mingw-w64

GCC for Windows 64 & 32 bits

Mingw-w64

Mingw-w64 is an advancement of the original mingw.org project, created to support the GCC compiler on Windows systems. It has forked it in 2007 in order to provide support for 64 bits and new APIs. It has since then gained widespread use and distribution.

The development and community are very active and welcoming with new contributors every month and simple installers.

Version 6 has been released

v6.0.0: 2018-09-17

Notable changes:

  • C++ __cxa_atexit thanks to Martin Storsjö and Liu Hao
  • Massive additions to support UCRT thanks to Martin Storsjö
  • Sync COM interface headers with Wine development thanks to Jacek Caban
  • WinRT additions thanks to Hugo Beauzée-Luyssen
  • ARM32 and ARM64 additions thanks to Martin Storsjö
  • CRT library api-ms-win-core additions thanks to Martin Storsjö
  • CRT library def file reorganization thanks to Martin Storsjö
And many other additions thanks to, but not limited to (in Alphabetical order)

You can also look at the full list of versions.

Headers, Libraries and Runtime

  • More than a million lines of headers are provided, not counting generated ones, and regularly expanded to track new Windows APIs.
  • Everything needed for linking and running your code on Windows.
  • Winpthreads, a pthreads library for C++11 threading support and simple integration with existing project.
  • Winstorecompat, a work-in-progress convenience library that eases conformance with the Windows Store.
  • Better-conforming and faster math support compared to Visual Studio's.

Tools

  • gendef: generate Visual Studio .def files from .dll files.
  • genidl: generate .idl files from .dll files.
  • widl: compile .idl files.

Friend projects

Mingw-w64 interacts a lot with other projects in order to help everyone move forward. Contributions have been going to and coming from these projects:

Most Recent Activity

Darold Smith posted a comment on discussion Help
16.08.2019

C++ executable with command line: C:\1_Data\1_Users\Darold\NOTES\NotesW64>notesw64 < HM370K20yr2-5.inp > HM370K20yr2-5.txt produces the error shown in the attached error message. The file exists in the directory path image. I have tried reinstallation with the same error. The output file is created but has 0 size. Computer is Windows 64 bit running Win Pro 7.

NightStrike posted a comment on discussion Open Discussion
16.08.2019

Only msys programs depend on the msys dll. Maintaining the build bot wasn't trivial, many of our slave providers disappeared, and react OS no longer provides the server for us. Do you have infrastructure you can share? I should point out that a full build of all languages and running the test suite takes several days. On Thu, Aug 15, 2019, 5:02 PM jungletek jungletek@users.sourceforge.net wrote: MSYS2 introduces the dependency for msys2.0.dll, so this is just another annoying thing to have to configure...

jungletek posted a comment on discussion Open Discussion
15.08.2019

MSYS2 introduces the dependency for msys2.0.dll, so this is just another annoying thing to have to configure and include for someone who simply wants the ability to be able to use MinGW on the Windows command-line, as well as use the same compiler in CLion, etc. Why is this all this nonsense, excuses, and apathy a thing in 2019? How expensive is processor time on the cloud (AWS, Azure, etc.) to run a build-bot to push out these releases so that we can have on-time(ish) updates in the way that MANY...

Doug Semler modified ticket #811
09.08.2019

std::sqrtf, std::sqrtl not supported

Doug Semler posted a comment on ticket #811
09.08.2019

This is a bug in libstdc++ (it also exists on linux gcc), and not the runtime. This issue has actually been known since 2017: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89279

Old Wolf 2 created ticket #811
09.08.2019

std::sqrtf, std::sqrtl not supported

Doug Semler posted a comment on ticket #809
06.08.2019

You are correct with respect to the modifiable values C89 2.1.2.2 Hosted environment specifies this exact behavior. I haven't looked at C11 but I do remember that the pointers in the array are implementation defined, but non-const. Basically it boils down to argc and argv are owned by the program once they are passed to main. Note: Program termination is the return from main or call to exit() Programs are free to: 1) Modify the value in argv[j"> , where j is an index up to and including the NULL...

Jannick posted a comment on ticket #809
06.08.2019

Umm ... Section 5.1.2.2.1 of C11 (Program startup) might be an obstacle to naively free up argv at some point: "The parameters argc and argv and the strings pointed to by the argv array shall be modifiable by the program, and retain their last-stored values between program startup and program termination." I am inclined to interpret the term 'modifiable' to allow the program to change the strings pointed to by the argv array including reallocations. If true the program could legally free up those...

Kai Tietz posted a comment on ticket #809
06.08.2019

Am Di., 6. Aug. 2019 um 12:06 Uhr schrieb Jannick jannick0815@users.sourceforge.net: Hi Kai, Happy to suggest a patch. Just to confirm: Would GetProcessHeap / HeapAlloc / HeapFree be the WIN32 API functions you expect to be used? Regards, J. As crt creates a heap, and we want that arguments remain valid as long as possible TLS-routines might be executed on exit, it would be best to use here GlobalAlloc (well LocalAlloc is actually the same!). Of most interesting is here the point, when this memory...

Jannick posted a comment on ticket #809
06.08.2019

Hi Kai, Happy to suggest a patch. Just to confirm: Would GetProcessHeap / HeapAlloc / HeapFree be the WIN32 API functions you expect to be used? Regards, J. From: Kai Tietz ktietz70@users.sourceforge.net Sent: Tuesday, August 6, 2019 10:44 AM To: [mingw-w64:bugs"> 809@bugs.mingw-w64.p.re.sourceforge.net Subject: [mingw-w64:bugs"> Re: #809 __tmainCRTStartup: copied argv causing memory leakage Hello, this memory leakage is well known. We could have used here instead stack, which would be even worse....