使用MXE

Question

让我们这样说：我们将创建一个需要跨平台的库，我们选择GCC作为编译器，它在Linux上运行得非常好，我们需要在Windows上编译它，我们让MinGW来完成工作

MinGW尝试实现在Windows上编译C ++的本机方式，但它不支持某些功能，如mutex和threads。

我们有MinGW-W64是支持这些功能的MinGW的分支，我想知道哪一个使用？知道GCC是最常用的C ++编译器之一。或者最好在Linux上使用MSVC（VC ++），在Linux上使用GCC，并使用CMake处理独立编译器？

提前致谢。

Answer 1

就个人而言，我更喜欢基于MinGW的解决方案，它可以在Linux上进行交叉编译，因为有许多平台独立的库几乎不可能（或者是一个庞大的PITA）在Windows上构建。（例如，使用./configure脚本来设置其构建环境的那些。）但是，如果必须./configure和{{1}，即使在Linux上交叉编译所有这些库及其依赖项也很烦人。他们每个人自己。这就是MXE的用武之地。

从评论中，您似乎担心依赖性。如果必须单独交叉编译每个库，那么在交叉编译时，它们在构建环境设置方面成本很高。但是有MXE。它构建了一个交叉编译器和大量独立于平台的库（如boost，QT和许多不太值得注意的库）。使用MXE，作为解决方案，提升变得更具吸引力。我已经使用MXE来构建一个依赖于Qt，boost和libexiv2的项目，几乎没有问题。

使用MXE

增强线程

要执行此操作，请先安装mxe：

make

然后构建您想要的包（git clone -b master https://github.com/mxe/mxe.git和gcc）：

boost

带有MXE的C ++ 11线程

如果您仍然喜欢C ++ 11线程，那么MXE也可以这样做，但它需要两阶段编译gcc。

首先，检查mxe的主（开发）分支（这是安装它的常规方法）：

make gcc boost

然后构建git clone -b master https://github.com/mxe/mxe.git和gcc而不做任何修改：

winpthreads

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

现在，重新编译--enable-threads=posix并享受您的C ++ 11主题。

gcc

注意：您必须这样做，因为默认配置使用WINAPI而不是posix pthreads支持Win32线程。但GCC的libstdc ++，即实现make gcc和std::thread的库，没有使用WINAPI线程的代码，因此它们添加了一个预处理器块，用于从std::mutex和std::thread中删除启用Win32线程时的库。通过使用std::mutex和winpthreads库，我们让winpthreads作为粘合代码，为GCC提供正常的pthreads接口，而不是让GCC尝试在它的库中与Win32接口。使用并使用WINAPI函数来实现pthreads库。

最后的注释

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

引文

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

Answer 2

如果您想要可移植性，请使用标准方法 - <thread> C ++ 11库。

如果你不能使用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。

Answer 3

你绝对应该使用Boost。它真的很棒，可以做所有事情。

说真的，如果您不想使用Boost.Thread不支持的某些同步原语（例如std::async），请查看Boost库。当然这是一个额外的依赖，但如果你不害怕这一点，你将享受Boost的所有优势，如交叉编译。

了解Boost.Thread与C ++ 11主题here之间的差异。

Answer 4

我认为当您需要选择多平台工具或工具集时，这是一个相当通用的注意事项列表，对于很多这些工具或工具集，您可能已经有了答案;

工具支持，如果某些东西不起作用，您将如何获得支持;社区和供应商有多强大？
原生目标支持，该工具对目标平台的理解程度如何？
优化潜力？
图书馆支持（现在和将来）？
平台SDK支持，如果需要？
构建工具（尽管这里没有直接询问，它们是否适用于两个平台;大多数流行的工具都可以使用）。

我看到的一件事似乎并未真正处理过;

目标应用程序的期望是什么？

你提到你正在构建一个库，那么应用程序将使用它以及应用程序所期望的

。

这里作为目标应用程序的约束决定了系统最基本的方面，即用于构建它的工具。应用程序如何使用该库;

该应用程序需要什么API和什么样的API？

您想提供什么样的API（C风格，C ++类或组合）？

它使用的是什么运行时，它是相同的，还是会有冲突？

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

我认为Hans Passant的评论......

做什么先行

......确实在这里适用。

既然你提到过; mingw-builds的{{1}}支持mingw-w64等，thread在Windows上构建，64 bit和32 bit。

MinGW与MinGW-W64对比交叉编译中的MSVC（VC ++）

4 个答案:

使用MXE

带有MXE的C ++ 11线程

最后的注释

引文