starałem się budować gdal-1.10.0 (http://trac.osgeo.org/gdal/wiki/DownloadSource) używając mingw64 (od http://sourceforge.net/projects/mingwbuilds/files/host-windows/ x64-4.8.0 uwalnianiu-POSIX SEH-rev2.7z). Skompilowałem gdal-1.10.0 pod standardową wersją MinGW (32-bit) bez problemu.błąd Linków GetACP pod mingw64 (MinGW-buduje)
Powodem muszę przełączyć się mingw64 jest to, że średnia 32-bitowy MinGW dystrybucja nie obsługuje C++ 11 funkcji takich jak std::thread oraz (podejrzewam) inne funkcje jak dobrze. Ale pojawia się błąd łącząc w końcu mówi mi coś o
undefined reference to '__imp_GetACP'
(lub inną nazwą zdobione jeśli używam wariant 32-bitowy z mingw64/MinGW-buduje). BTW, próbowałem różnych wersji mingw64, w tym 64-bit, 32-bit, seh, sjlj, ale wszystkie dały ten sam błąd o GetACP().
zrobiłem jakąś pracę domową i znaleźć kilka wskazówek dla podobnego zadania kompilacji: http://www.gaia-gis.it/spatialite-3.0.0-BETA/mingw64_how_to.html#env według powyższej stronie internetowej, wydaje się, że sugerują one problem ma zrobić z WOW64 i poprawnej wersji dll windows nie może być Używane, ponieważ okno automatycznie określa to za Ciebie w zależności od tego, czy 64-bitowa aplikacja wykonująca połączenie jest 32-bitowa czy . Jest to podobno problem dla mingw64 , ponieważ kompilator gcc jest 64-bitowy, ale msys jest beznadziejnie 32-bitowy.
Jednak od czasu, gdy wypróbowałem także wersje 32-bitowe, powyższe nie wyjaśnia błędu w postaci . Co więcej, starałem się w brudny sposób skomentować wszystkie połączenia z GetACP(), , ponieważ nie dbam o strony kodowe i to wszystko dla moich celów. Co dziwne, kompilacja jest w porządku (w nowym źródle po skomentowaniu GetACP()), ale nadal zgłaszany jest ten sam błąd łącza. Sprawdziłem, czy libkernel32.a, są w folderze lib, a także postępowałem zgodnie z instrukcjami na powyższym blogu, aby skopiować dll z c:\windows\system32 i umieścić je w podfolderach Mingw z odpowiednią zmianą nazwy. Błąd łącza pozostaje. To tutaj przestałem hakować po prawie dwóch dniach bezskutecznie. Nie mogę zrozumieć, dlaczego cały kod źródłowy nie zawiera pojedynczego wywołania funkcji i nadal otrzymuję błąd łącza.
Czy ktoś może wyjaśnić, co mogło spowodować ten problem między gdal i mingw64, i jak to naprawić?
Ponadto ogólne pytanie dotyczące mingw64 polega na tym, że naprawdę jest w stanie obsłużyć funkcje POSIX-a w postaci ? Widzę nazwy pakietów, takie jak x64-4.8.0-release-posix-seh-rev2.7z, ale pamiętam, że ludzie z MinGW powiedzieli, że nigdy nie będą obsługiwać pełnego posixa.
P.S. Testuję to na Windows Server 2008 R2, 64-bitowy.
Aktualizacja: Kompletne etapy budowy gdal-1.10.0 pod MinGW64 (MinGW-wersje) są:
$./configure
Następnie Edit GDALmake.opt, znajdź GDAL_ROOT i zamień format dysku cygwin na format dos/mingw, np. Zmiana:
GDAL_ROOT = /d/temp/build/gdal-1.10.0
do
GDAL_ROOT = d:/temp/build/gdal-1.10.0
Wymień
CONFIG_LIBS = $(GDAL_ROOT)/$(LIBGDAL)
z
CONFIG_LIBS = $(GDAL_ROOT)/$(LIBGDAL) -liconv
Wreszcie
$ make && make install && cp apps/*.exe /usr/local/bin/
To jest doskonałe. Przetestowano przy użyciu x64-4.8.1-release-posix-seh-rev0 (mingw-builds). Uwaga: wygląda na to, że w GDALmake.opt istniał już -liconv. Ale w jakiś sposób nie został wykryty pod MinGW64 (per mingw-builds). – tinlyx
Dlaczego ten błąd występuje? –