I am an Chinese programmer, and I found that the current MinGW-w64 versions (11.2, 12.2, 13.2, released by niXman or winlibs) have two problems with directories which contain Chinese characters.

Normally, MinGW-w64 is installed in directory "C:\MinGW64". If my program "hello.cpp" saved in directory "C:\myprogs", then following compiling command will success:

C:\MinGW64\bin\g++.exe "C:\myprogs\hello.cpp" -o "C:\myprogs\hello.exe" -Wall -Wextra -pipe -I"C:\MinGW64\include" -I"C:\MinGW64\x86_64-w64-mingw32\include" -I"C:\MinGW64\lib\gcc\x86_64-w64-mingw32\13.2.0\include" -I"C:\MinGW64\lib\gcc\x86_64-w64-mingw32\13.2.0\include\c++" -L"C:\MinGW64\lib" -L"C:\MinGW64\x86_64-w64-mingw32\lib" -static-libstdc++ -static-libgcc

Problem 1: if the path of my programs contains Chinese characters, then compilation will fail.
For example, MinGW-w64 is installed in normal directory "C:\MinGW64", my program "hello.cpp" saved in directory "C:\我的程序"，I typed the following compiling command::

C:\MinGW64\bin\g++.exe "C:\我的程序\hello.cpp" -o "C:\我的程序\hello.exe" -Wall -Wextra -pipe -I"C:\MinGW64\include" -I"C:\MinGW64\x86_64-w64-mingw32\include" -I"C:\MinGW64\lib\gcc\x86_64-w64-mingw32\13.2.0\include" -I"C:\MinGW64\lib\gcc\x86_64-w64-mingw32\13.2.0\include\c++" -L"C:\MinGW64\lib" -L"C:\MinGW64\x86_64-w64-mingw32\lib" -static-libstdc++ -static-libgcc

The compilation command will give message:
cc1plus.exe: fatal error: C:\鎕ello.cpp: No such file or directory
compilation terminated.

Apparently, path "C:\我的程序\hello.cpp" is not correctly processed, it was processed as "C:\鎕ello.cpp".

If I rename the program file "hello.cpp" to "测试hello.cpp", and typed the following compiling command:
C:\MinGW64\bin\g++.exe "C:\我的程序\测试hello.cpp" -o "C:\我的程序\测试hello.exe" -Wall -Wextra -pipe -I"C:\MinGW64\include" -I"C:\MinGW64\x86_64-w64-mingw32\include" -I"C:\MinGW64\lib\gcc\x86_64-w64-mingw32\13.2.0\include" -I"C:\MinGW64\lib\gcc\x86_64-w64-mingw32\13.2.0\include\c++" -L"C:\MinGW64\lib" -L"C:\MinGW64\x86_64-w64-mingw32\lib" -static-libstdc++ -static-libgcc

The compilation command will give message:
C:\骀礶llo.cpp: In function 'int main()':
C:\骀礶llo.cpp:7:36: error: expected ';' before 'return'
7 | cout << "Hello, World!" << endl
| ^
| ;
8 |
9 | return 0;

Apparently, path "C:\我的程序\测试hello.cpp" is not correctly processed, it was processed as "C:\骀礶llo.cpp".

Problem 2: If the installation directory of MinGW-w64 contains Chinese Characters, then compilation will fail.
For example, MinGW-w64 is installed in directory "C:\编译器MinGW64" which contains Chinese characters, one tried to compile program "C:\myprogs\hello.cpp" with the following command:

C:\编译器MinGW64\bin\g++.exe "C:\myprogs\hello.cpp" -o "C:\编译器hello.exe" -Wall -Wextra -pipe -I"C:\编译器MinGW64\include" -I"C:\编译器MinGW64\x86_64-w64-mingw32\include" -I"C:\编译器MinGW64\lib\gcc\x86_64-w64-mingw32\13.2.0\include" -I"C:\编译器MinGW64\lib\gcc\x86_64-w64-mingw32\13.2.0\include\c++" -L"C:\编译器MinGW64\lib" -L"C:\编译器MinGW64\x86_64-w64-mingw32\lib" -static-libstdc++ -static-libgcc

The compilation will fail, and the output message is:

C:/MinGW64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find C:/MinGW64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o: No space left on device
C:/MinGW64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find C:/MinGW64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/crtbegin.o: No space left on device
C:/MinGW64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lstdc++: No space left on device
C:/MinGW64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgcc: No space left on device
C:/MinGW64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgcc_eh: No space left on device
C:/MinGW64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgcc: No space left on device
C:/MinGW64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgcc_eh: No space left on device
C:/MinGW64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find C:/MinGW64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/crtend.o: No space left on device
collect2.exe: error: ld returned 1 exit status

It seems that the Chinese characters "编译器" are ignored in some internal stage.

Please check the two problems. Thanks.

BTW, MinGW-w64 8.1.0 does not have such problems.

I have windows 10 and I installed mingw32 https://github.com/niXman/mingw-builds-binaries/releases/download/13.2.0-rt_v11-rev1/i686-13.2.0-release-posix-dwarf-msvcrt-rt_v11 -rev1.7z
It compiles the program perfectly, but doesn't run it.

Hello there,

This build is provided via Chocolatey on Windows (https://community.chocolatey.org/packages/mingw) where I installed the latest version (12.2.0.03042023). I am trying to run gdb with gef (python extensions). However, on load I get the error ModuleNotFoundError: No module named '_ctypes'.

Googling the error gave basically 2 results:

• people on Linux saying that installing libffi fixes the error. I am on Windows however.
• issue msys2/MINGW-packages#4572 that implemented a patch 1900-ctypes-dont-depend-on-internal-libffi.patch. I do not know if this is applicable here.

Env info:

Edition	Windows 11 Pro N
Version	22H2
Installed on	‎7/‎05/‎2022
OS build	22621.1413
Experience	Windows Feature Experience Pack 1000.22639.1000.0

 ; gcc --version
gcc.exe (x86_64-posix-seh-rev2, Built by MinGW-W64 project) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The bundled python is

# pwd = C:\programdata\chocolatey\lib\mingw\tools\install\mingw64\opt\bin
 ; .\python3.9.exe
Python 3.9.10 (heads/mingw-v3.9.10-dirty:12d1cb5b7c, Dec  9 2022, 03:24:49)  [GCC UCRT 12.2.0 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import _ctypes
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named '_ctypes'

I get the errors when compiling anything that uses threads...

C:/mingw64/lib/gcc/x86_64-w64-mingw32/13.2.0/include/c++/bits/std_thread.h: In function 'bool std::operator==(thread::id, thread::id)':
C:/mingw64/lib/gcc/x86_64-w64-mingw32/13.2.0/include/c++/bits/std_thread.h:330:26: error: no match for 'operator==' (operand types are 'std::thread::native_handle_type' and 'std::thread::native_handle_type')
  330 |     return __x._M_thread == __y._M_thread;
      |            ~~~~~~~~~~~~~ ^~ ~~~~~~~~~~~~~
      |                |                |
      |                |                std::thread::native_handle_type
      |                std::thread::native_handle_type

and

C:/mingw64/lib/gcc/x86_64-w64-mingw32/13.2.0/include/c++/thread: In function 'bool std::operator<(thread::id, thread::id)':
C:/mingw64/lib/gcc/x86_64-w64-mingw32/13.2.0/include/c++/thread:79:26: error: no match for 'operator<' (operand types are 'std::thread::native_handle_type' and 'std::thread::native_handle_type')
   79 |     return __x._M_thread < __y._M_thread;
      |            ~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~
      |                |               |
      |                |               std::thread::native_handle_type
      |                std::thread::native_handle_type

I was wondering if by some small chance you had a 9.x or 10.x that has win32 threading?

Hi,
there is a patch for win32 threads from Jamaika1 https://github.com/Jamaika1/mingw_std_threads
Is it possible/reasonable to apply it for builds?
I tried it, in simple cases it looks like working.
Thanks for your job and Happy NY!

Norton 360 found a the virus Trojan.Gen.MBT in your download mingwInstaller.exe
I downloaded from https://github.com/niXman/mingw-builds-binaries
See Norton's report below

Filename: padlock.dll
Threat name: Trojan.Gen.MBTFull Path: C:\Users\wmcre\mingw64\opt\lib\engines-3\padlock.dll

On computers as of 
10/12/2023 at 2:31:20 AM

Last Used 
10/12/2023 at 2:31:20 AM

Startup Item 
No
Launched 
No
Threat type: Virus. Programs that infect other programs, files, or areas of a computer by inserting themselves or attaching themselves to that medium.

padlock.dllThreat name: Trojan.Gen.MBT
Locate

Few Users
Fewer than 50 users in the Norton Community have used this file.

New
This file was released 10 days  ago.

High
This file risk is high.

Source: External Media

File Actions

File: C:\Users\wmcre\mingw64\opt\lib\engines-3\padlock.dllBlocked

File Thumbprint - SHA:
Not available
File Thumbprint - MD5:
Not available

Hi there,

I'm having trouble compiling simple test program on windows 10 with long list of includes provided via '@response_file' argument

The full error is:

gcc.exe: fatal error: cannot execute 'C:/Tools/x86_64-12.2.0-release-win32-seh-rt_v10-rev0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/as.exe': CreateProcess: No such file or directory
compilation terminated.

The weirdly glued path to assembler program is valid therefore I don't understand what is the issue here?

You can try to recreate the problem by compiling simple main.c file with nothing in it but main function using command
gcc @includes.txt main.c
includes.txt

On linux this is not the problem. I assume it has something to do with windows 32k CreateProcess command length limitation? But isn't that the reason why respone files were invented?

I'm sorry for my ignorance!
I don't understand from the documentation how to build it
Thanks
Ron

Hey guys I ran into some issues when building the repo on Windows.

$ ./build --mode=gcc-4.8.1 --arch=x86_64
-> Checking OS bitness... 64-bit
-> Checking OS type... MINGW32_NT-10.0-18363
-> Checking for installed packages... --> installing required packages...
:: Synchronizing package databases...
 mingw32 is up to date
 mingw64 is up to date
 ucrt64 is up to date
 clang32 is up to date
 clang64 is up to date
 msys is up to date
warning: lndir-1.0.3-2 is up to date -- skipping
warning: git-2.37.2-1 is up to date -- skipping
warning: subversion-1.14.0-6 is up to date -- skipping
warning: tar-1.34-3 is up to date -- skipping
warning: zip-3.0-3 is up to date -- skipping
warning: p7zip-17.04-1 is up to date -- skipping
warning: make-4.3-3 is up to date -- skipping
warning: patch-2.7.6-1 is up to date -- skipping
warning: automake-wrapper-11-4 is up to date -- skipping
warning: autoconf-wrapper-15-1 is up to date -- skipping
warning: autoconf-archive-2019.01.06-1 is up to date -- skipping
warning: libtool-2.4.6-14 is up to date -- skipping
warning: flex-2.6.4-2 is up to date -- skipping
warning: bison-3.8.2-3 is up to date -- skipping
warning: gettext-0.21-2 is up to date -- skipping
warning: gettext-devel-0.21-2 is up to date -- skipping
warning: wget-1.21.3-1 is up to date -- skipping
warning: sshpass-1.09-1 is up to date -- skipping
warning: texinfo-6.8-4 is up to date -- skipping
warning: autogen-5.18.16-3 is up to date -- skipping
warning: dejagnu-1.6.3-1 is up to date -- skipping
 there is nothing to do
done
Using downloaded toolchain
-> i686 toolchain
--> i686 toolchain is not installed ---> i686-8.1.0-release-posix-sjlj-rt_v6-rev0.7z downloaded
--> unpack i686-8.1.0-release-posix-sjlj-rt_v6-rev0.7z... done
-> x86_64 toolchain
--> x86_64 toolchain is not installed ---> x86_64-8.1.0-release-posix-sjlj-rt_v6-rev0.7z downloaded
--> unpack x86_64-8.1.0-release-posix-sjlj-rt_v6-rev0.7z... done
-> start building x86_64-4.8.1-multilib-posix-sjlj-rt_v9 with "c,c++,fortran" languages supported
-> libiconv-x86_64
---> libiconv-1.17.tar.gz downloaded
---> libiconv-1.17.tar.gz unpacked
---> patched
---> configured
---> built
---> installed
-> libiconv-i686
---> libiconv-1.17.tar.gz downloaded
---> libiconv-1.17.tar.gz unpacked
---> patched
---> configured
---> built
---> installed
-> zlib-x86_64
---> zlib-1.2.12.tar.gz downloaded
---> zlib-1.2.12.tar.gz unpacked
---> patched
---> configured
---> built
---> installed
-> zlib-i686
---> zlib-1.2.12.tar.gz downloaded
---> zlib-1.2.12.tar.gz unpacked
---> patched
---> configured
---> built
---> installed
-> gmp
---> gmp-6.2.1.tar.xz downloaded
---> gmp-6.2.1.tar.xz unpacked
---> configured
---> built
---> installed
-> mpfr
---> mpfr-4.1.0.tar.xz downloaded
---> mpfr-4.1.0.tar.xz unpacked
---> configured
---> built
---> installed
-> mpc
---> mpc-1.2.1.tar.gz downloaded
---> mpc-1.2.1.tar.gz unpacked
---> configured
---> built
---> installed
-> isl
---> isl-0.12.2.tar.lzma downloaded
---> isl-0.12.2.tar.lzma unpacked
---> patched
---> configured
---> built
---> installed
-> cloog
---> cloog-0.18.4.tar.gz downloaded
---> cloog-0.18.4.tar.gz unpacked
---> patched
---> after_patch executed
---> configured
---> built
---> installed
-> mingw-w64-download
---> mingw-w64 downloaded
-> mingw-w64-api
--> Doesn't need to download
--> Unpack doesn't need
---> configured
---> built
---> installed
-> mingw-w64-crt
--> Doesn't need to download
--> Unpack doesn't need
---> configured
---> built
---> installed
-> winpthreads-x86_64
--> Doesn't need to download
--> Unpack doesn't need
---> configured
---> built
---> installed
-> winpthreads-i686
--> Doesn't need to download
--> Unpack doesn't need
---> configured
---> built
---> installed
-> mingw-w64-runtime-post
--> Doesn't need to download
--> Unpack doesn't need
---> installed
-> binutils
---> binutils-2.38.tar.xz downloaded
---> binutils-2.38.tar.xz unpacked
---> patched
---> configured
--> building...
error!

I used MSYS2 MinGW x64.

Should I be using a different program such as MSYS2 MinGW?

@Vuniverse0 hello!

could you please fix the installer so it can continue work with changed archive names ?

for example, before the archives had the name: i686-12.2.0-release-posix-dwarf-rt_v10-rev2.7z
now it will be called as i686-12.2.0-release-posix-dwarf-msvcrt-rt_v10-rev2.7z, i.e. the only thing that has changed is was added a new field about used runtime. it can one of msvcrt or ucrt.

best!

After I compiled and used powershell to run Fortran "Hello world" program, it could run but nothing printed in screen. If I use cmd instead of powershell, everything became OK.
I found that comparing to MSYS2 bin directory, some DLL is missing in mingw64\bin. I tried copy every DLL in MSYS2 bin directory (see my repo mingw64_gfortran_dll) to mingw64\bin, and then I found that everything became OK in powershell.

When I use stl and run the program,it shows me a error that _ZSt28__throw_bad_array_new_lengthv1.I had added the /path/mingw64/bin into the environment.How could I solve this problem?Thanks.

MinGW 8.1.0 release (and previous) on https://sourceforge.net/projects/mingw-w64/files/ has had fortran as part of the enabled-languages build script.

As it turns out fortran was used and users are missing it from the MinGW package that I've built, as reported at https://forum.qt.io/topic/133616/qt-6-2-2-and-mingw-9-0-0-does-not-deliver-a-fortran-compiler/

Adding fortran doesn't break things as seen at https://github.com/cristianadam/mingw-builds/actions/runs/1709598486 and it makes the 7zip archive 5MB bigger and the installed size 44MB bigger.

strings.exe -h

--unicode={default|show|invalid|hex|escape|highlight}
-U {d|s|i|x|e|h} Specify how to treat UTF-8 encoded unicode characters

option {s} - show is error ,can't use , d|i|x|e|h is ok, only s cant work and warning:

strings.exe: invalid argument to -U/--unicode: s

I downloaded this package: i686-12.2.0-release-win32-sjlj-rt_v10-rev0.7z
When I run gdb, an error message pop up saying something like: Unable to find entry point GetSystemTimePreciseAsFileTime in KERNEL32.dll.
I got this error on win7, 64bit system. I have tried on another win10 system, and the gdb works fine.
Does this package support win7?

(gdb) layout
Undefined command: "layout". Try "help".
(gdb)

I downloaded:

[x86_64-12.2.0-release-posix-seh-rt_v10-rev0.7z](https://github.com/niXman/mingw-builds-binaries/releases/download/12.2.0-rt_v10-rev0/x86_64-12.2.0-release-posix-seh-rt_v10-rev0.7z)

However the issue is that it shows gdb version is GNU gdb (GDB) 11.2 which is outdated. Is there a way to update the gdb version?

The installer hangs on Extraction. windows 10 64 bit. Tried to install it with win32, something like jiji and not posix standard then after downloading mingw the installer hangs on Extraction.

I do not know whether this is a (known) bug or not, but I've spend quite some time with this issue before I figured it out and I think this should either be fixed or noted as a known issue, I could not find any info about it anywhere.

I have Windows installed in a VM using VirtualBox and I have a shared folder between host and client OS. I have placed MinGW-w64 in the root folder of the share which is mounted to Z: in Windows. I have added "Z:\mingw32\bin" to the PATH environment variable and compiling works as expected, but linking fails with:

//VBoxSvr/Share/mingw32/bin/../lib/gcc/i686-w64-mingw32/13.1.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find //VBoxSvr/Share/mingw32/bin/../lib/gcc/i686-w64-mingw32/13.1.0/../../../../i686-w64-mingw32/lib/../lib/crt2.o: Invalid argument //VBoxSvr/Share/mingw32/bin/../lib/gcc/i686-w64-mingw32/13.1.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find //VBoxSvr/Share/mingw32/bin/../lib/gcc/i686-w64-mingw32/13.1.0/crtbegin.o: Invalid argument //VBoxSvr/Share/mingw32/bin/../lib/gcc/i686-w64-mingw32/13.1.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find //VBoxSvr/Share/mingw32/bin/../lib/gcc/i686-w64-mingw32/13.1.0/crtend.o: Invalid argument collect2.exe: error: ld returned 1 exit status

Regardless of what I do, I cannot get it to work - most likely because of the "//" in the path. Copying MinGW-w64 to C:\mingw32 and adjusting the PATH variable accordingly makes the issue disappear.

I was hoping to find a build with Ada (gnat).
But, especially, if it exists, a 64-bit Ada.
?is that possible?
Thx, Rod

Error:
C:/Compilers/mingw32/bin/../lib/gcc/i686-w64-mingw32/13.2.0/../../../../i686-w64-mingw32/bin/ld.exe: unrecognized emulation mode: windows

Steps to reproduce:

• Download and install latest version of MingW x86 to be compatible with both x64 and arm64 and set the environment path
• Download and install eclipse
• Eclipse --> Help --> Install New Software --> All Sites
• Sel: Autotools Support, Dev Tools, Dev Tools SDK
• Restart Eclipse
• New Project --> MingW and Hellow world selected
• Project --> Properties --> C++ BUILD --> MingW C++ Linker
• Add the fallowing -mwindows
• Try and compile the hellow world project and watch the error happen.

Please tag a 12.1.0-rt_v10-rev0 release. https://github.com/niXman/mingw-builds already has the necessary patches.

With the sjlj exceptions binaries there was a 32bit library shipped.

With this I could provide x86 and x64 binaries. Now this is not the case anymore and if I try to compile with -m32 i get an error:
Fatal error: selected target format 'pe-bigobj-i386' unknown

I could not find anything about this in the release notes.
Am I missing something or doing something wrong here?
Is this not provided by intention? What could I use instead?

Hi, are these builds are considered "official releases", in the same vein as the older builds at https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/? I ask because I don't see this repository or any of these releases being linked from https://github.com/niXman/mingw-builds.

Building and executing a simple "Hello World!" with the newest release yields a segmentation fault:

x86_64-13.1.0-release-win32-seh-ucrt-rt_v11-rev1

#include <iostream>
using namespace std;
int main(int argc, char* argv[])
{
    cout << "Hello World!" << endl;
    return 0;
}

Build:

g++.exe -fdiagnostics-color=always -g main.cpp -o main.exe

vscode:

x86_64-12.2.0-release-win32-seh-ucrt-rt_v10-rev2

Building, debugging, executing with the prior release works like a charm.

System

Tested on a windows sandbox system:

OS Name:                   Microsoft Windows 10 Enterprise
OS Version:                10.0.19041 N/A Build 19041
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Standalone Workstation
OS Build Type:             Multiprocessor Free
Registered Owner:          N/A
Registered Organization:   N/A
System Manufacturer:       Microsoft Corporation
System Model:              Virtual Machine
System Type:               x64-based PC
Processor(s):              1 Processor(s) Installed.
                           [01]: Intel64 Family 6 Model 165 Stepping 2 GenuineIntel ~2712 Mhz
BIOS Version:              Microsoft Corporation Hyper-V UEFI Release v4.0, 11/1/2019
Windows Directory:         C:\Windows
System Directory:          C:\Windows\system32
Boot Device:               \Device\HarddiskVolume2
Total Physical Memory:     4,095 MB
Available Physical Memory: 1,819 MB
Virtual Memory: Max Size:  5,823 MB
Virtual Memory: Available: 3,209 MB
Virtual Memory: In Use:    2,614 MB
Page File Location(s):     C:\pagefile.sys

I am going to use Linux to build this for Windows.

./build --mode=gcc-4.8.1 --arch=x86_64 this would build it for Linux when compiling on a Linux system I believe, so how would I build it for Windows using a Linux machine?

I usually have a few compilers and I don't leave them all in the PATH. So just access by typing the whole path to it. In this, I ended up discovering that the binary i686 and x86_64, gcc version 12.2.0, rev2, when called that way, that is, without being in the PATH, present the following error of missing libwinpthread-1.dll. The problem can be easily resolved by copying libwinpthread-1.dll to "mingw64\libexec\gcc\x86_64-w64-mingw32\12.2.0". After that, I checked all the executables there and they all have a dependency on this dll.

I also verified that the executables in "mingw64\x86_64-w64-mingw32\bin" depend on libwinpthread-1.dll and libstdc++-6.dll (if I'm not mistaken it's just ld.gold.exe).

In my opinion, there are 3 ways to solve this:

1. the user himself makes the copy, when he witnesses the error and understands how to mitigate it;
2. the binaries are released with the copies already made; or
3. the binaries are compiled statically.

MSYS2 has recently changed the default environment from msvcrt-based MINGW64 to ucrt-based UCRT64: https://www.msys2.org/news/

Maybe it's time for mingw-builds to release ucrt-based binaries?

Environment:
CPU: inter i7-10750H 2.6GHz
Mingw ver. x86_64-13.2.0-release-win32-seh-ucrt-rt_v11-rev0 (both ucrt and msvcrt have this error)

Problem:
When I tapped backspace(<-) in gdb, backspace(<-) would become a space(' ') in Command Window and I couldn't remove it
But Mingw ver. 12.2.0 works well.

sorry for my poor English... qwq

hello I installed the latest version of MinGW and it doesn't work. I put in the C:/MinGW/bin in the path so g++ works. I launch eclipse I specify the toolchain MingGW when creating a project and any includes doesn't work. not <iostream> nothing. I tried using both the installer and the release zip versions. nothing works.

The version I had working was the 32 bit version from 2014 on sourceforge. the issue with that one is it compiles the dll to 32 bit and then won't run from java

One day, I thecked the total amount of files in MinGW-w64 GCC release package v13.2, and found that there are about 14,856 files.

I felt that there may be some unnecessory files. So I checked the amount of files in each directory, and found there are a lot of files which seem to be unnecessory.

(1) There is a directory named "terminfo" in .\opt\lib\ whose total size is only 8.91M but contains 2,777 files and 42 directories. Besides, there is a dublicated copy of "terminfo" in .\opt\share, which also contains 2,777 files and 42 directories.

It is discribed in webpage "https://www.man7.org/linux/man-pages/man5/terminfo.5.html" as follows:
Terminfo is a database describing terminals, used by screen-oriented programs such as nvi(1), lynx(1), mutt(1), and other curses applications, using high-level calls to libraries such as curses(3X). It is also used via low-level calls by non-curses applications which may be screen-oriented (such as @clear@(1)) or non-screen (such as @tabs@(1)).

I also heard that "Terminfo" exists in /usr/share/terminfo in Linux. So, maybe Terminfo is important in Linux. However, is it necessory to keep two copied in GCC release?

(2) The directory of .\opt\share\doc contains 3,994 files. Especially, the sub-directory "openssl\html\man3" contains 3,848 files. I don't think it is necessory to keep so many doc files in GCC release.

(3) Totally, there are 2,829 ".pyc" files. I don't think all these files are absolutely necessary to GCC. So I deleted all of them, then run GCC and GDB once, and found that 64 ".pyc" files generated automatically. I guess, only those 64 ".pyc" files are necessory to GCC release.

Totally, if I compress ".\opt\lib\terminfo" and ".\opt\share", and delete unnecessory ".pyc" files, the total amount files of GCC release will drop to about 5860 files.

My suggestion is to decrease files in GCC release by removing unnecessory files. At least, the directory of .\opt\share\doc which contains 3,994 files should be compressed or deleted.

I was interestrd in getting the MCF thread model build after seeing the Release notes.

• MCF thread model was added

However, there is no corresponding build to download. Win32 and posix thread models are the only options available for the binaries in this release (just like the previous releases):

https://github.com/niXman/mingw-builds-binaries/releases/tag/13.2.0-rt_v11-rev0

Where can I download the MCF build?

please help me to install mingw

I noticed that the Win32 version still includes the pthread DLL in the distribution, even though it is unused. Is there a reason for that? Not that it matters much.

WinGW-W64 version x86_64-12.1.0-release-posix-seh-rt_v10-rev3
When compiling OPENCV I get next error

:/mingw64/lib/gcc/x86_64-w64-mingw32/12.1.0/include/c++/numeric:298:38: error:
__binary_op' cannot be used as a function
298 | __init = __binary_op(__init, *__first);
| ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~

I installed x86_64-13.1.0-release-win32-seh-msvcrt-rt_v11-rev1.7z in https://github.com/niXman/mingw-builds-binaries/releases, my anti-malware software notifies me that gcov.exe is malware. Also VirusTotal indicates that it is malware (see https://www.virustotal.com/gui/file/0dce658138023ab7aefb4d0ddd82aac8020fe4e7881db8a27cf0c4180bbfd618/detection). I suggest you investigate.

At https://github.com/niXman/mingw-builds-binaries/releases/tag/13.1.0-rt_v11-rev0 there are no binaries listed.

This is due to https://github.com/niXman/mingw-builds-binaries/actions/runs/5036456410/jobs/9032617873 which fails with:

(1/1) Updating the info directory file...
bad command line: " --mode=gcc-13.1.0". terminate.
done

I guess 9eef2ae broke dues to newlines.

Is there an old version, like 8.1.0 or earlier?

For some reason when I try to download the latest mingw binary it triggers my antivirus saying "Gen:Variant.Ransom.Hive.9", this is with version "13.1.0-rt_v11-rev1". However the previous version "12.2.0-rt_v10-rev2" doesn't cause this. I am unsure if this is a false positive or if it's actually an issue.

The following program will fail under g++ 12.

g++ version 12.2.0 (x86_64-posix-seh-rev2, Built by MinGW-W64 project)

OS: Windows 11

#include <iostream>
using namespace std;

int main()
{
    char s[256];
    cin >> s;
    cout << s;
    return 0;
}

Compile and run

g++ test.cpp
./a

Then the program fail at cin >> s, and output nothing.

Hello,
We currently use your binaries for our GitHub CI pipeline. We're running into linking issues that were fixed in binutils 2.40 (rust-lang/rust#112368 for context).
As binutils 2.39 is over a year and a half old at this point, is it possible to get a binary release here that includes a newer version of binutils?

Thank you.