MinGW-w64 的 ar.exe 在尝试构建静态库时找不到库

Question

几天来，我一直试图让 MinGW-w64 在我的系统上工作，主要是因为它有更新的 GCC 版本，但我要么设置错误，要么 MinGW-w64 本身存在一些奇怪的问题.

我现在已经下载了i686-w64-mingw32-gcc-4.7.2-release-win32_rubenvb，将其解压缩到C:/Dev/mingw-ruben，并将路径C:/Dev/mingw-ruben/bin 添加到$PATH 环境变量中。

我正在尝试构建的是SFML 2，它带有一个 CMake 文件。运行 CMake 会正常工作，编译器会被识别并通过所有测试。 CMake 还在C:/Dev/mingw-ruben/bin文件夹中找到ar.exe。生成 MinGW Makefile 后，我切换到 Windows 命令行并运行 mingw32-make install。 问题出在哪里，我得到了错误：

mingw-ruben\bin\ar.exe: mingw-ruben/lib/libopengl32.a: No such file or directory

或者对于网络库

mingw-ruben\bin\ar.exe: mingw-ruben/lib/libws2_32.a: No such file or directory

错误似乎很明显，检查时确实没有libopengl32.a 或libws2_32.a 在mingw-ruben/lib/，但文件实际上位于C:/Dev/mingw-ruben/i686-w64-mingw32/lib。

现在我如何告诉 ar/make/cmake 不仅要在 mingw-ruben/lib 目录中搜索，还要在 mingw-ruben/i686-w64-mingw32/lib 中搜索？

将i686-w64-mingw32 子文件夹中的所有内容复制到mingw-ruben 根文件夹是否是个好主意？

附带说明：我可以再次调用 mingw32-make install，该过程将继续，但在尝试将我的应用程序与 SFML 链接时，我在 SFML 中遇到了许多未解决的 glXYZ 函数符号错误。

更多信息：我使用的是 Windows 8 x64，但我认为这并不重要，是的，我尝试过 MSYS，但它不能解决我的任何问题。

我做错了吗？我需要专门配置吗？

Answer 1

2015 年 1 月编辑

现在 SFML 2.2 已经发布了，这不再是问题，在链接静态时你必须自己链接 SFML 的依赖项。

2014 年 1 月编辑

从提交 165f2b1888 和 f784fe4c07（包含在稳定版 SFML 2.1 中）开始，支持 MinGW-w64 编译器。

然而，在与各方进一步讨论时，发现sfml_static_add_libraries marco 是一个相当丑陋的黑客。简而言之，它解压缩了静态依赖项并将它们的 obj 文件包含到 SFML 库本身中。这是一个最明显的问题，当您尝试使用您自己的 GLEW 版本时，由于 SFML 已经在使用其内部版本，因​​此失败了。这个问题被带到the forum 并被推了很久，直到 Laurent 最终让步并采用了正确的链接依赖项的方式，这意味着你现在必须自己链接它们。

截至提交dbf01a775b，它不包含在 SFML 2.1 的稳定版本中，当静态链接到 SFML 时，必须在 finally 应用程序中链接 SFML 依赖项。

---

原创

在 IRC 上进行了一番交谈后，我们已经弄清楚了。 它与 MinGW 无关，但都是 SFML 的错。为了在静态链接时减少 SFML 的依赖项列表，开发人员决定手动从每个库（opengl32、ws2_32、...）中提取符号，这显然不是一个人做事的方式，并且违反了一些 ODR 规则。然后发生实际错误，因为开发人员假设该库将位于文件夹 mingw/lib 但对于 MinGW w64，它位于单独的目录 mingw/version/lib 中，因此 ar.exe 没有找到该库。

解决方案

删除对sfml_static_add_libraries 宏的调用，然后重新编译。之后，您必须链接静态链接的所有依赖项，就像它应该的那样。

Answer 2

我认为这可能是您下载的 gcc 发行版的问题。

对这个问题稍加了解就可以在这里提出鲁本的问题：

https://unix.stackexchange.com/questions/45277/executing-binary-file-file-not-found

在我看来与此有关（尽管它是关于 linux 而不是 win）

几个月前我在使用 gcc 4.7.0 linux->win 交叉编译器时遇到了类似的问题（丢失文件的名称不同）。所以直到现在我都使用标准的 ubuntu mingw-w64 包，就在昨天我再次尝试 i686-w64-mingw32-gcc-4.7.2-release-linux64_rubenvb.tar.xz 并且它在其他相同的环境中没有问题以前的版本因“..ar.exe: ...没有这样的文件”而失败。有时我也在 Windows 中开发，然后我使用http://www.mingw.org/，这对我来说更容易在 Win 中设置。它只支持 32 位目标，但对于我的项目来说已经足够了。