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



几天来,我一直在努力让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-rubenbinar.exe: mingw-ruben/lib/libopengl32.a: No such file or directory

或者对于网络库

mingw-rubenbinar.exe: mingw-ruben/lib/libws2_32.a: No such file or directory

这个错误看起来很明显,经过检查,mingw-ruben/lib/中确实没有libopengl32.alibws2_32.a,但文件实际上位于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,但它不能解决我的任何问题。

我做错什么了吗?我必须特别配置吗?

2015年1月编辑

现在SFML 2.2已经发布,这不再是一个问题,并且在链接静态时必须自己链接SFML的依赖项。

2014年1月编辑

从稳定版本SFML 2.1中包含的commit 165f2b1888和f784fe4c07开始,支持MinGW-w64编译器。

然而,在与不同党派进一步讨论时,人们发现sfml_static_add_librariesmarco是一个相当丑陋的黑客。简而言之,它将静态依赖项解包,并将它们的obj文件包含到SFML库中。这是一个最明显的问题,当尝试使用您自己版本的GLEW时,由于SFML已经在使用其内部版本,所以失败了。这个问题被带到了论坛上,并被推了很长一段时间,直到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宏的调用,然后重新编译。之后,您必须链接静态链接的所有依赖项,就像它应该的那样

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

对这个问题的一点了解给出了鲁本的问题:

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

在我看来,这似乎与此有关(尽管这是关于linux的,而不是胜利)

几个月前,我在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位目标,但对于我的项目来说,这已经足够了。

相关内容

  • 没有找到相关文章

最新更新