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 8 has been released

v8.0.0: 2020-09-18

Notable changes:

  • New Hyper-V headers and libraries by Biswapriyo Nath
  • Many headers updated from Wine by Jacek Caban.
  • ARM math improvements by Martin Storsjö
  • floating point fixes by Liu Hao
  • many *printf compatibility fixes by Liu Hao and Martin Storsjö
  • massive Windows App Store API updates by Steve Lhomme
  • winstorecompat library updates by Martin Storsjö
  • __USE_MINGW_ANSI_STDIO now automatically enabled in C99 and C11 mode when not using UCRT by Pali Rohár
  • wdm and ddk updates by Zebediah Figura
  • UCRT for Windows Store Apps (-lucrtapp) by Martin Storsjö
  • Audioclient and ActivateAudioInterfaceAsync API updates by Liu Hao
  • DirectX SDKs are now always installed
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

Royi posted a comment on discussion Open Discussion
01.10.2020

I saw that in the project page it is written that: Better-conforming and faster math support compared to Visual Studio's. I was wondering what does it mean? I was under the impression it uses Windows C libary with its math functions. Does MinGW use GCC's libm? If not, what's the difference? Is there a way to use libm on Windows with MinGW64? Thank You.

Nils Nolde posted a comment on discussion Help
29.09.2020

I need to compile boost-python 1.73.0 with MinGW64 on Fedora's rawhide, so that I can build Python bindings for Windows 10 64bit. And unfortunately the only library missing from Fedora's mingw64-boost package is boost-python, argggh! Actually all dependencies are packaged on Fedora for MinGW64, which is quite nice. So I'm trying to build myself with: wget https://dl.bintray.com/boostorg/release/1.73.0/source/boost_1_73_0.tar.bz2 tar -xjf boost_1_73_0.tar.bz2 && cd boost_1_73_0 ./bootstrap.sh # in...

zaghp modified a comment on ticket #856
28.09.2020

Hi Thank you for the reply. Why you assume that a local variable va is modified under the hood by a different function? As long as you don't pass reference to it, you are not able to modify its contents for an outer function. That's interresting, as soon as I read that line I was like "what an idiot". But then, I realized that the issue here was actually the misleading gcc/libc/... from my distribution because, well it "works" even though I'm passing the va_list as an argument and not as a reference...

zaghp posted a comment on ticket #856
28.09.2020

Hi Thank you for the reply. Why you assume that a local variable va is modified under the hood by a different function? As long as you don't pass reference to it, you are not able to modify its contents for an outer function. That's interresting, as soon as I read that line I was like "what an idiot". But then, I realized that the issue here was actually the misleading gcc/libc/... from my distribution because, well it "works" even though I'm passing the va_list as an argument and not as a reference...

Kai Tietz posted a comment on ticket #856
28.09.2020

Hello, Sorry for telling you, but your assumptions about passing va_list as argument, and how it behalfs is plain wrong. So your test-code is invalid. Why you assume that a local variable va is modified under the hood by a different function? As long as you don't pass reference to it, you are not able to modify its contents for an outer function. int foo(va_list argp) { return va_arg(argp, int); } void zoo(const char *fmt, ...) { va_list argp; argp=va_start(argp, fmt); fprintf(stderr, fmt, foo(argp),...

Kai Tietz posted a comment on ticket #853
28.09.2020

Hmm, sorry. I mixed your report up. There was another report with code sample, which claimed that va_list would be broken. Sorry about that. Nevertheless you should report this to gcc people too. As it is more a target-library issue in gcc AFAICS. Regards, Kai Am Mo., 28. Sept. 2020 um 15:27 Uhr schrieb Brecht Sanders brechtsanders@users.sourceforge.net: @ktietz70 I'm sorry, but I'm not following where you think this wrong assumtion was made. Is this in both gcc and pkg-config source code? Or are...

Sanmayce posted a comment on ticket #855
28.09.2020

For what is worth the OS is Windows 7 Pro, also the quick checking of a textual file shows the GCC binary works "PROPERLY": D:\Satanichi_aka_Nakamichi_2020-Jun-09>dir 06/11/2020 09:16 AM 55,397 lzsse2.cpp 06/11/2020 09:16 AM 1,316,439 Nakamichi_Ryuugan-ditto-1TB_btree.c 09/06/2019 11:50 AM 969,050,128 NCBI_FTP_Homo_sapiens_(human)_GCA_000001405.28_GRCh38.p13_genomic.fna.Nakamichi 06/15/2019 02:37 AM 3,313,087,324 q 01/07/2018 05:26 PM 191,644 Satanichi_GCC730_64bit.exe 06/11/2020 09:16 AM 198,144...

Brecht Sanders posted a comment on ticket #853
28.09.2020

@ktietz70 I'm sorry, but I'm not following where you think this wrong assumtion was made. Is this in both gcc and pkg-config source code? Or are you referring to some other code?

Sanmayce modified a comment on ticket #855
28.09.2020

The same said the GCC guy in the link above: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97215#c4 (In reply to Andrew Pinski from comment #2) You need b if you don't want \r\n to be turned into just \n. At 11,945th line I use: if ((fp = fopen(argv[1">, "rb")) == NULL) { printf("Nakamichi: Can't open '%s' file.\n", argv[1">); exit(13); } 1"> As far as I investigated, the problem is that fread() reads less (around 860 bytes) than specified. 2"> Also, as I wrote: This bug never appeared with files 1GB...

Sanmayce modified a comment on ticket #855
28.09.2020

The same said the GCC guy in the link above: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97215#c4 (In reply to Andrew Pinski from comment #2) You need b if you don't want \r\n to be turned into just \n. At 11,945th line I use: if ((fp = fopen(argv[1">, "rb")) == NULL) { printf("Nakamichi: Can't open '%s' file.\n", argv[1">); exit(13); } 1"> As far as I investigated, the problem is that fread() reads less (around 860 bytes) than specified. 2"> Also, as I wrote: This bug never appeared with files 1GB...