MinGW vs MinGW- w64 vs MSVC (vc++)交叉编译

MinGW vs MinGW-W64 vs MSVC (VC++) in cross compiling

本文关键字：vs vc++ 交叉编译 MSVC MinGW- w64 MinGW      更新时间：2023-10-16

让我们这样写:我们要创建一个需要跨平台的库，我们选择GCC作为编译器，它在Linux上工作得很好，我们需要在Windows上编译它，我们有MinGW来做这项工作。

MinGW试图实现一种本地方式在Windows上编译c++，但它不支持mutex和threads等特性。

我们有MinGW- w64，它是MinGW的一个分支，支持这些功能，我在想，该用哪个?知道GCC是最常用的c++编译器之一。或者更好地使用Windows上的MSVC (vc++)和Linux上的GCC，并使用CMake来处理独立的编译器?

提前感谢。

就我个人而言，我更喜欢在Linux上交叉编译的基于MinGW的解决方案，因为有许多与平台无关的库几乎不可能(或巨大的PITA)在Windows上构建。(例如，那些使用./configure脚本来设置他们的构建环境。)但是交叉编译所有这些库和它们的依赖关系即使在Linux上也是很烦人的，如果您必须自己分别对它们进行./configure和make编译的话。这就是MXE的用武之地。

从注释来看，您似乎担心依赖关系。在交叉编译时，如果您必须单独交叉编译每个库，那么它们在构建环境设置方面的成本很高。但是有MXE。它构建了一个交叉编译器和大量独立于平台的库(如boost、QT和许多不太知名的库)。有了MXE, boost作为一种解决方案变得更有吸引力。我已经使用MXE构建了一个依赖于Qt、boost和libexiv2的项目，几乎没有任何麻烦。

使用MXE增强线程

要做到这一点，首先安装mxe: 
git clone -b master https://github.com/mxe/mxe.git

然后构建你想要的包(gcc和boost):

make gcc boost

c++ 11 thread with MXE

如果你仍然喜欢c++ 11线程，那么MXE也是可以的，但它需要gcc的两阶段编译。

首先，签出mxe的主(开发)分支(这是安装它的正常方式):

git clone -b master https://github.com/mxe/mxe.git

不修改gcc和winpthreads:

make gcc winpthreads

编辑mxe/src/gcc.mk。找到以$(PKG)_DEPS :=开头的行，并将winpthreads添加到该行的末尾。找到--enable-threads=win32并将其替换为--enable-threads=posix。

现在，重新编译gcc，享受你的c++ 11线程。

make gcc

注意:你必须这样做，因为默认配置支持使用WINAPI而不是posix pthreads的Win32线程。但是GCC的libstdc++，实现std::thread和std::mutex的库，没有使用WINAPI线程的代码，所以他们添加了一个预处理器块，当Win32线程启用时，从库中剥离std::thread和std::mutex。通过使用--enable-threads=posix和winpthreads库，而不是让GCC在它的库中尝试与Win32接口，它不完全支持，我们让winpthreads充当胶水代码，为GCC提供一个正常的pthreads接口，并使用WINAPI函数来实现pthreads库。

<标题>

您可以通过将-jm和JOBS=n添加到make命令来加快这些编译速度。-jm，其中m是一个数字，表示同时构建m包。JOBS=n，其中n是一个数字，表示使用n进程构建每个包。因此，实际上，它们是相乘的，所以只选择m和n，这样m*n最多不会比您拥有的处理器内核数量多多少。例如，如果你有8个核心，那么m=3, n=4将是正确的。

<标题>引用

http://blog.worldofcoding.com/2014_05_01_archive.html#windows

如果需要可移植性，请使用标准方法-

如果你不能使用c++ 11, pthread可以解决，尽管vc++不能编译它。

你不想同时使用这两个吗?然后，只需编写线程的抽象层。例如，您可以这样写class Thread: 

class Thread
{
public:
   explicit Thread(int (*pf)(void *arg));
   void run(void *arg);
   int join();
   void detach();
   ...

然后，编写您想要支持的每个平台的实现。例如,

+src
|---thread.h
|--+win
|--|---thread.cpp
|--+linux
|--|---thread.cpp

之后，配置编译脚本，在windows上编译win/thread.cpp，在linux上编译linux/thread.cpp。

您绝对应该使用Boost。它真的很棒，而且无所不能。

说真的，如果你不想使用一些同步原语，Boost。线程不支持(如std::async)，看看Boost库。当然，这是一个额外的依赖，但如果你不害怕它，你将享受到Boost的所有优点，比如交叉编译。

了解Boost和Boost之间的区别。线程和c++ 11线程

我认为当您需要选择多平台工具或工具集时，这是一个相当通用的考虑事项列表，对于其中的许多问题，您可能已经有了答案;

  • 工具支持，如果某些东西不起作用，你将从谁以及如何获得支持;社区和供应商有多强大?
  • 本机目标支持，该工具对目标平台的理解程度如何?
  • 优化潜力?
  • 库支持(现在和中期将来)?
    • 平台SDK支持，如果需要的话?
  • 构建工具(虽然这里没有直接询问，但它们在两个平台上都工作吗?大多数流行的都有)。

我看到似乎没有真正处理的一件事是;

目标应用程序期望什么?

你提到你正在构建一个库，那么什么应用程序将使用它，应用程序期望什么。

这里的约束是目标应用程序，指示了系统的最基本方面，以及用于构建它的工具。应用程序将如何使用库;

  • 该应用程序需要什么API和什么样的API ?
  • 你想提供什么样的API (C风格，vs. c++类，或组合)?
  • 它使用的是什么运行时，它是相同的，还是会有冲突?

考虑到这些，以及目标应用可能仍然未知的事实;尽可能保持灵活性。在这种情况下，尽量保持与gcc, mingw-w64和msvc的兼容性。它们都提供了广泛的C++11语言支持(确实，有些比其他的更多)，并且通常得到其他流行库的支持(即使这些库现在不需要)。

我认为汉斯·帕桑的评论……

先做有效的

…

既然你提到了;mingw-w64的mingw-builds支持thread等，posix在Windows上构建，包括64位和32位。

相关文章：