Link error with GetACP under mingw64 (mingw-builds)

Question

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.

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'

(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().

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.

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.

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

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. I am testing this on a Windows Server 2008 R2, 64-bit.

---

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

$./configure

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

to

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

Replace

CONFIG_LIBS =   $(GDAL_ROOT)/$(LIBGDAL)  

with

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

Finally,

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

Answer 1

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)   

with

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

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