Mingw vs MinGW-W64 and others

Cause: I recently compiled qemu (for Windows) on Ubuntu, and my target machine is win7 64bit, so naturally installed a mingw64-x-gcc.

Later, we found that the 64-bit environment could not be set up, and many dependent libraries were not supported. Therefore, we had to reinstall the 32bit environment.

At this time, the problem arises./usr/bin has the following:

I586-mingw32msvc-gcc
I686-w64-mingw32-gcc
I686-w64-mingw32-gcc-4.6
X86_64-w64-mingw32-gcc
X86_64-w64-mingw32-gcc-4.6

Then I was forced, do not know which to use (before this do not know the existence of mingw-w64 ).

South Korea's little brother is also a bit knowledgeable,

# Install required packages $ Sudo apt-Get update $ Sudo apt-Get install mingw32-x-gcc For Windows 64bit If you want to build for Windows 64 bit, you shocould install this package, mingw64-x-gcc

The article is as follows:

++

Reprinted: http://www.cnblogs.com/foohack/p/3877276.html

Refer to the original text of the Memorandum for some reference: workshop? At = Master 452 rows.
Try the Q & A body. First, you have to go a long distance, starting with Win32. Otherwise, it will be easy to mess up ......
Q: What is Win32?
A: Well, 32 is actually 32-bit? Not necessarily.
Formally speaking, Win32 mainly refers to the Win32 subsystem running on the Windows NT kernel. Currently, most Windows programs run on this subsystem, and the System32 directory is not called system64.
Although the 32 language source does come from "32-bit ".
Q: Why is there another win64?
It is certain that 64 here refers to the 64-bit target platform, because there is no such ambiguity.
It is worth noting that in msvc, the 32-bit environment (of course, the running Intel CPU-compatible PC) predefined macro _ Win32, however, the 64-bit environment predefines both _ Win32 and _ win64.
By the way, usually 64-bit mainly refers to x86_64 (known as amd64 by Microsoft). This x86-compatible infrastructure was first developed by AMD and later developed by Intel em64t ).
64-bit itanium also has _ win64, but it is generally invisible and has nothing to do with mingw and is not officially supported now, no matter ......
For mingw, there is a similar pitfall here: the predefined macro must first check 64-bit. The actual situation is more complex.
Q: What's the difference between mingw and MinGW-W64?
This is a key issue, ...... It is a long story. It is hard to answer without preparation.
First, mingw is a tool for porting GNU (including GCC compiler, GNU binutils, and gdb debugger) on Win32, Which is fork from cygwin. At the beginning, only 32 bits were considered. Compared with cygwin, it emphasizes performance and dependency reduction instead of POSIX compatibility.
In addition to the above tools, mingw also provides a runtime environment suitable for Win32. Among them, the C standard library is implemented directly by Microsoft's msvcrt distributed with windows. Mingw's Runtime Library depends on msvcrt and other system libraries.
The mingw GCC depends on the mingw runtime, libgcc, and other system libraries. Compiled programs generally depend on these libraries, so they will be written to the default specs (you can use gcc-dumpspecs to view them) otherwise, you may need to manually specify a large number of-l options to compile or link a program.
The target platform is represented with three tuples, And the mingw in that year refers to the i386-pc-mingw32. Here, i386 can also be isung ...... The name of the 32-bit x86 instruction set architecture. The intermediate PC is optional, indicating the manufacturer name. Mingw32 indicates the system name.
Note that, in fact, the 32 in the standard "terminology" mingw32 is fixed. In addition, these cases are generally fixed. The source code configurations such as GCC are also hardcoded.
Then, some people think it is not enough because it only supports 32 bits. One of the main figures here is Kai tietz, the main Maintainer of MinGW-W64. He wanted mingw to provide extended x64 support for his work, but his attitude was unfriendly. So angry fork out, this is the origin of MinGW-W64.
Visible, MinGW-W64 and the original mingw has a source, but independent of the two projects.
W64 although the intention is win64, but it is also a proprietary term, in the three element group to occupy the vendor name, such as common: i686-w64-mingw32. (In the GCC source code configuration file, *-w64-mingw32 and *-pc-mingw32 are treated separately .)
The MinGW-W64 supports both 32-bit and 64-bit. It even supports 32-bit and 64-bit cross-compiling (enable the mingw release supported by multilib, for example, mingw-builds can be specified with-M32 or-M64 ).
Obviously, w64 has nothing to do with the supported architecture. The above i686 is not a 64-bit platform (and it can be seen that the 32 here has nothing to do with the architecture ). The corresponding triple of 64 characters is supported as a x86_64-w64-mingw32.
...... It is easy to worry that neither of these two projects is dead, but it is still easy to make a mistake due to these literal reasons. For the convenience described below, the original mingw is called mingw.org.
It is important that only MinGW-W64 is officially supported by GCC (although the mingw32 platform is a second-class citizen ). Kai tietz has the submission permission for the GCC official repo.
Therefore, the use of MinGW-W64 GCC is generally more comprehensive support than mingw.org updates, so now generally recommended MinGW-W64 release.
Here ...... Keith Marshall, who maintains mingw.org, and other GCC officials such as Kai tietz, performed the following on Bugzilla: gcc.gnu.org/bugzilla/show_bug.cgi? Id = 52015.
Keith Marshall expressed indignation at the use of mingw, A MinGW-W64, to create confusion. Well, this is also a fact.
Of course, it doesn't mean that mingw.org is useless. *-W64-mingw32 is backward compatible in principle *-pc-mingw32, but there are also some interface differences. BSD stream dt _ * can be used on mingw.org, there is no MinGW-W64. (Although dt _ * is not recommended ......)
Q: What is distribution )?
This statement is used to be borrowed from Linux and other software.
Similar to linux kernels, mingw.org and MinGW-W64 are relatively concentrated in the development of specific software packages (mingw Runtime Library), rather than providing the entire out-of-the-box environment.
Therefore, in addition to some official compilation versions, many people customize encapsulation Based on mingw runtime for users to download the entire environment, and some also provide package management services. This is the release version. Generally, the environment and/or installation package that can be directly decompressed with path are provided.
Early famous include TDM-GCC and rubenvb.
Previously Used mingw.org, but now mainly to the MinGW-W64.
Compare the new release with the MinGW-W64 in the beginning. One of the most famous releases should be mingw-builds. Basically, in recent years (after gcc4.7) Windows has been able to support the latest version, and supports cross-compilation.
Mingw-builds initially had its own project on sf.net, but later said it was required to join the MinGW-W64 project as official builds, so stop more, updates are in the MinGW-W64, however, it seems that the current MinGW-W64 does not provide the only official release, so it is also called personal builds.
In addition, one of the maintenance personnel of dinkumware, Microsoft's VC ++ standard library, mr. STL (Stephen T. lavavejj), is released. By default, Specs adds-STD = C ++ 11.
There is also the mingw release version of The msys2 Project (there may be new chaos here, which will be discussed later), which was also developed by a group of mingw-builds personnel recently (4.9.1) it is several hours faster than mingw-builds.
Other releases can refer to the mingw-w64.sourceforge.net, the update is not so fast.
Finally, you can compile the program by yourself. But it is best not to do this unless you have to (the GCC compilation process and hacking are really powerless ). It is not recommended to repeat it.
Q: Why should I emphasize updates?
If you don't want to use new features to generate higher quality code, you don't have to stare at the chaotic mingw of the above versions. Even if compatibility is required, you can use antiques (escape ......
Mingw is particularly important for the c ++ front-end and cannot be replaced at this stage. Msvc2013, represented by the default Abi cutting-edge of the system -- front-end is still defective ...... Various bugs.
GCC also has various silly bugs, but at least for the front-end, it cannot beat Cl (Microsoft C & C ++ optimizing compiler ).
VC ++ debugging support is certainly much better, but it is useless to integrate debugging with the compiler.
Well, clang ++? When can libc ++ run smoothly on Windows? Even though mingw is compatible with libgcc of mingw. As for clang-Cl compatible with VC ++, it seems that it is still tossing Microsoft's potholes Abi black box (this is not like the itanium Abi public documentation used by GCC on most platforms ), don't count on it for a year and a half.
Q: What is the exception model and thread model? Which one is better?
Both are for C ++ implementation (G ++, libgcc, libsup ++, and so on.
First, the exception model. The C ++ standard does not specify how exceptions are implemented. The itanium Abi used by mingw GCC does not specify how to implement it (but some public interfaces are defined). This part should be implemented on your own.
GCC generally provides stub implemented by sjlj (setjmp/longjmp of C. For x86, dwarf2 debugging information can be used. The difference between the two lies in that sjlj is more common, but even if an exception is not thrown, but an implicit exception is passed using an exception neutral style, it also has runtime overhead. The compatibility of dwarf2 (considering the calling of multi-layer C ++ and c dll) is relatively poor, but there is no such overhead.
The ABI is not compatible with the two. (If you know that C ++ is not compatible with different implementations, the same compiler and the same platform are not compatible with yourself ......) -- The former depends on a DLL like libgcc_s_sjlj.dll, and the latter is similar to libgcc_s_dw2.dll. The old one may not have such a suffix difference.
In addition, libstdc ++ is obviously dependent on the C ++ standard library, but the DLL with the same name may depend on different types. Therefore, when multiple versions of mingw GCC are mixed and the path is not cleaned up, the link may fail because the symbolic definition cannot be found. This is not the most pitfall. Sometimes, when GDB loads a DLL in different locations, it crashes at runtime, not just a path problem ...... In this case, take a tool such as system internals's process exporler to check whether the DLL loaded by the process is expected.
Why is there something so difficult to use, just like VC ++ ...... In fact, on Win32 x86, the ideal solution should be the same as VC ++ Based on Seh (Windows structured exception handling), but Borland's patent on this did not expire for a few days ...... So you know.
There is no patent trouble on x64. The implementation of sjlj and seh is generally Seh.
Second, thread model.
The Windows Thread API is very different from POSIX (pthread), while the STD: thread of Iso c ++ indicates that the interface is very close to pthread.
Therefore, to implement these interfaces on libstdc ++, the first thing that relies on pthread porting libwinpthread on Win32 is the POSIX thread model. Therefore, the DLL such as the libwinpthread-1.dll needs to be carried during the release.
As for the Win32 thread model, GCC mailing list has been mentioned, but it has not been implemented yet. That is to say, the implementation of iso c ++ is residual and cannot be used. If you only want to use Win32 multi-threaded APIs, you can use them.
Therefore, it depends on the specific needs. POSIX is usually used for better compatibility.
Q: What is msys? What is the difference between mingw and mingw?
Msys provides a set of "systems" and the triple is *-PC-msys.
Compared with mingw, msys is closer to cygwin (emphasizing POSIX compatibility) and provides a sysroot (which has/bin and/etc below). Therefore, it is easier to port the POSIX Environment Program.
The cost is also true. Native compiled programs in the msys environment generally depend on the msys Runtime Library (of course, it is much lighter than cygwin ).
Therefore, the conventional practice is that if you only develop Windows programs, you can use mingw instead of using msys native compiler to build them. Of course, it's okay to use tools such as SH on msys. It's better to use tools like GNU than cmd. (Although there are also a lot of trivial bugs .)
Q: What is msys2 and mingw release on msys2?
Literally, the msys 2.0. Compared with 1.0, it is more like cygwin (for example,/etc/fstab configuration ). The project is hosted on sf.net.
One feature is the archlinux porting Package Manager Pacman that can be deployed independently under/mingw32 (i686-w64-mingw32) And/mingw64 (x86-w64-mingw32) at the same time.
The download dependency is quite convenient (that is, there is no reliable image, and the network speed may be very poor ). For more information, see archlinux wiki.
Although cross-compilation is not supported, it can be installed separately, which is more stable and reliable than mingw-builds-M32 and-M64.
Only the dwarf2 exception model and POSIX thread model are provided. Packages are not as rich as archlinux, but many of them are commonly used, saving you from the trouble of compiling by yourself. We recommend that you use mingw and related tools for a long time.
Although the rollback fails, the version is a problem. If a specific version of GCC is required, it is not applicable (for example, avoiding the pitfalls of GCC 4.9 ......), Unless you have the patience to find. xz manual installation.
Q: What files do deployment programs need to provide?
By default, Windows does not include the mingw runtime environment. Therefore, apart from the compiled program and the data that may be included, some DLL files must be prepared unless you have the patience to submit all static links.
Different versions, different languages, and different compilers compile different things. Which of the following statements is the simplest and most reliable (?) The method is to copy the executable program to the whiteboard test machine without an environment installed to see what is missing (but it may not be clear at a glance ).
A simple and reliable way is to use dependency Walker and other tools to view dependencies.
For C ++, libwinpthread can be saved unless POSIX thread is not used, generally, make sure that at least the three DLL mentioned in the above exception model and thread model are used. (Note that even if you do not show that the standard library is used, the code generated by the compiler may also be used.-Typical default:: Operator new, so you must bring libstdc ++ ).
Q: What new challenges are there?
Let's raise a question about GCC 4.9.
By default, the GCC 4.9 lto (optimized when linking) uses the new target file format. The generated file does not contain redundant binary code.
However, LTO has a specific phase (several more passes will be compiled internally), and the traditional static linker (AR) does not know the conventions here, so it turns out to be a good thing, after Upgrade 4.9, the-flto may fail to be found.
Now, the mingw release should have not implemented gcc-AR (running will prompt that linker plugin is not supported ). The-ffat-LTO-objects compilation option must be added for compatibility with earlier versions.


EOF

Mingw vs MinGW-W64 and others