mingw-w64

GCC for Windows 64 & 32 bits

This is an old revision of the document!


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

  • 32bit ARM thumb software math (Thanks to André Hentschel!).
  • New ftw() support for gcc-5.x support.
  • Experimental printf changes - Ability to print 128bit integers (%I128*) and Decimal Floats (%H, %D), disabled by default. Build the CRT with —-enable-experimental to use.
  • Updated OpenGL 4.5 headers.
  • Better DirectX 11 support.
  • Better Windows 7, 8/8.1 API support.

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.

Previous Versions

3.0

  • Required for GCC 4.8.
  • Much improved floating point math performance.
  • Improved MSVC intrinsics performance.
  • Addition of wide variants in C99 printf and scanf.
  • Partial C1X secure CRT support.
  • Partial MS Secure CRT templates for C++.
  • Vastly improved Windows 7 and 8 win32 API support.
  • POSIX-style Large File Support.
  • Winpthread: new library, pthreads implementation for Windows.
  • Winstorecompat: new library for Windows Store compatibility (WIP).

2.0

  • Expanded Windows Vista/7 API support.

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...