几天来，我一直在尝试让 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 还找到了 ar.exe在C:/Dev/mingw-ruben/bin文件夹。生成 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 时，我遇到了许多 Unresolved 符号错误 glXYZ SFML 中的函数。
更多信息:我在 Windows 8 x64 上，但我认为这并不重要，是的，我已经尝试过 MSYS，但它没有解决我的任何问题。
我做错了什么吗？我需要特别配置吗？
最佳答案
2015 年 1 月编辑
现在 SFML 2.2 已经发布，这不再是问题，您必须在链接静态时自己链接 SFML 的依赖项。
2014 年 1 月编辑
截至提交 165f2b1888和 f784fe4c07 , 包含在稳定版 SFML 2.1 中，支持 MinGW-w64 编译器。
然而，在与各方进一步讨论时发现，sfml_static_add_libraries marco 是一个相当丑陋的 hack。简而言之，它解压缩了静态依赖项并将它们的 obj 文件包含到 SFML 库本身中。这是最值得注意的问题，当您尝试使用您自己的 GLEW 版本时，由于 SFML 已经在使用其内部版本，该版本失败了。问题被带到the forum并被推来推去，直到 Laurent 最终屈服并采用正确的方式链接依赖项，这意味着您现在必须自己链接它们。
截至提交 dbf01a775b ，不包含在 SFML 2.1 的稳定版本中，当针对 SFML 进行静态链接时，必须在最终应用程序中链接 SFML 依赖项。
原创
在 IRC 上进行了一些讨论之后，我们已经弄明白了。
它与 MinGW 无关，但都是 SFML 的错。为了在静态链接的同时减少 SFML 的依赖项列表，开发人员决定手动从每个库(opengl32、ws2_32 等)中提取符号，这显然不是人们做事的方式并且违反了一些 ODR 规则。然后发生实际错误，因为开发人员假设库将位于文件夹 mingw/lib 但对于 MinGW w64，它位于单独的目录 mingw/version/lib 并且所以 ar.exe 没有找到库。
解决方案
删除对 sfml_static_add_libraries 宏的调用，然后重新编译。之后，您必须为静态链接链接所有依赖项，就像它应该的那样。
关于static-linking - MinGW-w6 4's ar.exe can' t 尝试构建静态库时找不到库，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12723383/