mingw64下的GetACP链接错误(mingw-builds) [英] Link error with GetACP under mingw64 (mingw-builds)

问题描述

我正在尝试构建gdal-1.10.0 ( http://trac.osgeo.org/gdal/wiki/DownloadSource )使用mingw64 (从 http://sourceforge.net/projects/mingwbuilds/files/host-windows/ x64-4.8.0-release-posix-seh-rev2.7z).我已经在下面编译了gdal-1.10.0 标准的MinGW(32位)版本没有问题.

I was trying to build gdal-1.10.0 (http://trac.osgeo.org/gdal/wiki/DownloadSource) using mingw64 (from http://sourceforge.net/projects/mingwbuilds/files/host-windows/ x64-4.8.0-release-posix-seh-rev2.7z). I have compiled gdal-1.10.0 under the standard MinGW (32-bit) version without a problem.

我必须切换到mingw64的原因是标准的32位MinGW发行版 不支持std::thread之类的c ++ 11功能，以及(我怀疑)其他功能，例如 出色地.但是最后我得到一个链接错误，告诉我一些有关

The reason I have to switch to mingw64 is that the standard 32-bit MinGW distribution does not support c++11 features like std::thread, and (I suspect) other features as well. But I get an linking error in the end telling me something about

undefined reference to '__imp_GetACP'

(如果我使用的是32位变体形式，则使用不同的修饰名称 mingw64/mingw-builds).顺便说一句，我尝试了不同版本的mingw64，包括 64位，32位，seh，sjlj，但都给出关于GetACP()的相同错误.

(or a different decorated name if I use the 32-bit variant from mingw64/mingw-builds). BTW, I tried different versions of mingw64, including 64-bit, 32-bit, seh, sjlj, but all gave the same error about GetACP().

我做了一些功课，并找到了一些有关类似编译任务的说明: http://www.gaia-gis.it/spatialite -3.0.0-BETA/mingw64_how_to.html#env 根据上述网站，看来他们暗示问题必须解决 与WOW64和Windows dll文件的正确版本不能使用，因为 Windows会根据32位还是32位自动为您确定 进行呼叫的64位应用程序.可能这是mingw64的问题 因为编译器gcc是64位，而msys是32位.

I did some homework and found some instructions for a similar compilation task: http://www.gaia-gis.it/spatialite-3.0.0-BETA/mingw64_how_to.html#env According to the above website, it seems that they suggest the problem has to do with WOW64 and the correct version of windows dll files cannot be used because windows automatically determines it for you depending on whether a 32-bit or 64-bit application making the call. This is supposedly a problem for mingw64 because the compiler gcc is 64-bit but msys is hopelessly 32-bit.

但是由于我也尝试了32位版本，因此上述内容似乎无法解释 错误. 还有，我以一种肮脏的方式试图注释掉所有对GetACP()的调用， 因为我并不是很在意代码页之类的内容. 奇怪的是，编译是可以的(仅在带有GetACP()的注释的最新资源上)，但是仍然报告相同的链接错误.我检查了libkernel32.a，libiconv.a是否在lib文件夹中，并且还按照上面博客中的说明从中复制了dll. c:\windows\system32并将它们放置在mingw子文件夹中，并进行适当的重命名.链接错误仍然存​​在.这是我花了将近两天没有成功之后才停止黑客攻击的地方.我不明白为什么整个源代码都不包含对该函数的单个调用，而我仍然收到链接错误.

But since I tried 32-bit versions as well, the above does not seem to explain the error. Even more, I tried in a dirty way to comment out all calls to GetACP(), because I don't really care about code pages and all that for my purposes. Strangely enough, compilation is OK (on a fresh source just with the GetACP()'s commented out), but the same link error is still reported. I checked that libkernel32.a, libiconv.a are in the lib folder, and also followed the instructions in the blog above to copy dll's out from c:\windows\system32 and place them in mingw subfolders with appropriate renaming. The link error remains. This is where I stopped hacking after spending almost two days on this without success. I can't understand why the entire source-code does not contain a single call to the function and I am still getting the link error.

谁能解释在gdal和mingw64之间可能导致此问题的原因， 以及如何解决?

Can anyone explain what might have caused this issue between gdal and mingw64, and how to fix it?

此外，有关mingw64的一个普遍问题是它是否真的能够支持 posix函数?我看到软件包名称，例如 x64-4.8.0-release-posix-seh-rev2.7z，但我记得MinGW人说 他们将永远不支持完整的posix.

Also, a general question about mingw64 is that is it really able to support posix functions? I see package names such as x64-4.8.0-release-posix-seh-rev2.7z, but I remember that the MinGW people said they will never support full posix.

P.S. 我正在64位Windows Server 2008 R2上对此进行测试.

P.S. I am testing this on a Windows Server 2008 R2, 64-bit.

更新: 在MinGW64(mingw-builds)下构建gdal-1.10.0的完整步骤是:

Update: The complete steps for building gdal-1.10.0 under MinGW64 (mingw-builds) are:

$./configure

然后， 编辑GDALmake.opt，找到GDAL_ROOT并将cygwin驱动器格式替换为dos/mingw格式，例如 更改:

Then, Edit GDALmake.opt, Find GDAL_ROOT and replace the cygwin drive format with dos/mingw format, e.g. Change:

GDAL_ROOT  = /d/temp/build/gdal-1.10.0

到

GDAL_ROOT =  d:/temp/build/gdal-1.10.0

替换

CONFIG_LIBS =   $(GDAL_ROOT)/$(LIBGDAL)  

使用

CONFIG_LIBS =   $(GDAL_ROOT)/$(LIBGDAL)   -liconv

最后，

$ make && make install && cp apps/*.exe /usr/local/bin/

推荐答案

我不小心遇到了相同的问题. 也许这是MinGW错误或配置文件错误，但是解决方案是添加 -liconv 到链接器标志的末尾，例如，替换

I have accidentally encountered the same problem. Maybe this is a MinGW bug or bad configuration files, but the solution is to add -liconv to the end of linker flags, for example, replace

CONFIG_LIBS =   $(GDAL_ROOT)/$(LIBGDAL)   

与

CONFIG_LIBS =   $(GDAL_ROOT)/$(LIBGDAL)   -liconv

在GDALmake.opt文件中(通过在Mingw目录中搜索文件中的GetACP找到).

in GDALmake.opt file (found by searching Mingw directory for GetACP in files).

这篇关于mingw64下的GetACP链接错误(mingw-builds)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！