Link-Fehler mit GetACP unter mingw64 (mingw-Builds)

Question

ich versuche gdal-1.10.0 (http://trac.osgeo.org/gdal/wiki/DownloadSource) mit mingw64 (von http://sourceforge.net/projects/mingwbuilds/files/host-windows/ x64-4.8.0-release-Posix-SEH-rev2.7z zu bauen). Ich habe gdal-1.10.0 unter der Standard MinGW (32-Bit) Version ohne ein Problem kompiliert.

Der Grund, warum ich zu mingw64 wechseln ist, dass die Standard-32-Bit-MinGW Verteilung nicht C++ 11 Funktionen wie std::thread nicht unterstützt, und (ich vermute) andere Funktionen als gut. Aber ich bekomme ein Verknüpfungsfehler am Ende sagen Sie mir etwas über

undefined reference to '__imp_GetACP' 

(oder einem anderen ergänzten Namen, wenn ich die 32-Bit-Variante von verwenden mingw64/mingw-Builds). BTW, versuchte ich verschiedene Versionen von mingw64, einschließlich 64-Bit, 32-Bit, seh, sjlj, aber alle gaben den gleichen Fehler über GetACP().

ich einige Hausaufgaben gemacht und fand einige Befehle für eine ähnliche Zusammenstellung Aufgabe: http://www.gaia-gis.it/spatialite-3.0.0-BETA/mingw64_how_to.html#env auf die oben genannte Website zufolge scheint es, dass sie legen nahe, das Problem mit WOW64 und der richtigen Version von Windows DLL-Dateien kann nicht zu tun hat seine verwendet, weil Windows automatisch für Sie bestimmt, je nachdem, ob eine 32-Bit- oder 64-Bit-Anwendung den Aufruf tätigt. Dies ist vermutlich ein Problem für Mingw64 , weil der Compiler gcc 64-Bit ist aber msys ist hoffnungslos 32-Bit.

Da ich aber auch 32-Bit-Versionen ausprobiert, scheinen die oben nicht der Fehler zu erklären. Noch mehr, versuchte ich auf eine schmutzige Art, alle Anrufe zu GetACP(), zu kommentieren, weil ich nicht wirklich Code-Seiten und alles das für meine Zwecke interessiere. Seltsamerweise ist die Kompilierung in Ordnung (auf einer frischen Quelle nur mit der GetACP() ist auskommentiert), aber der gleiche Link-Fehler wird noch gemeldet. Ich habe überprüft, dass libkernel32.a, libiconv.a sind in der lib Ordner, und folgte auch den Anweisungen im Blog oben, um DLL's aus c:\windows\system32 kopieren und in Mingw Unterordner mit entsprechenden Umbenennung platzieren. Der Verbindungsfehler bleibt bestehen. Hier hörte ich auf zu hacken, nachdem ich fast zwei Tage ohne Erfolg damit verbracht hatte. Ich kann nicht verstehen, warum der gesamte Source-Code keinen einzigen Aufruf der Funktion enthält und ich immer noch den Link-Fehler bekomme.

Kann jemand erklären, was dieses Problem zwischen gdal und mingw64, verursacht haben könnte, und wie man es repariert?

Auch eine allgemeine Frage über Mingw64 ist, dass es wirklich Posix-Funktionen unterstützen kann? Ich sehe Paketnamen wie x64-4.8.0-release-Posix-SEH-rev2.7z, aber ich erinnere mich, dass die MinGW Leute sagten sie nie voll Posix unterstützen.

P.S. Ich teste dies auf einem Windows Server 2008 R2, 64-Bit.

---

Update: Die vollständigen Schritte für den Aufbau gdal-1.10.0 unter MinGW64 (mingw-Builds) sind:

$./configure 

Dann bearbeiten GDALmake.opt, Finde GDAL_ROOT und ersetze das Cygwin-Laufwerksformat durch das Dos/Mingw-Format, z. Wechsel:

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

zu

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

ersetzen

CONFIG_LIBS = $(GDAL_ROOT)/$(LIBGDAL) 

mit

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

Schließlich

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

Answer 1

Ich bin zufällig auf das gleiche Problem gestoßen. Vielleicht ist dies ein MinGW Fehler oder schlechte Konfigurationsdateien, aber die Lösung ist -liconv bis zum Ende des Linker-Flags zum Beispiel hinzufügen,

CONFIG_LIBS = $(GDAL_ROOT)/$(LIBGDAL) 

mit

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

in ersetzen GDALmake.opt-Datei (gefunden durch Durchsuchen des Mingw-Verzeichnisses nach GetACP in Dateien).