Я пытался построить библиотеку GDAL-1.10.0 (http://trac.osgeo.org/gdal/wiki/DownloadSource) с использованием mingw64 (от http://sourceforge.net/projects/mingwbuilds/files/host-windows/ x64-4.8.0-релиз-POSIX-SEH-rev2.7z). Я скомпилировал gdal-1.10.0 под стандартную версию MinGW (32-разрядной версии) без проблем.ошибка Связь с GetACP под mingw64 (MinGW-сборки)
Причина я должен переключиться на mingw64 является то, что стандартный 32-битный MinGW распределение не поддерживает C++ 11 функций, таких как std::thread
, и (я подозреваю) другие функции, как хорошо. Но я получаю связь ошибка в конце концов говорит мне что-то о
undefined reference to '__imp_GetACP'
(или другой украшенной именем, если я использую 32-битный вариант из mingw64/MinGW-сборки). Кстати, я пробовал разные версии mingw64, включая 64-битный, 32-битный, seh, sjlj, но все они дали ту же ошибку около GetACP()
.
Я сделал домашнее задание и нашел некоторые инструкции для подобной компиляции задачи: http://www.gaia-gis.it/spatialite-3.0.0-BETA/mingw64_how_to.html#env Согласно вышеуказанному сайту, кажется, что они предполагают, что проблема имеет с WOW64 и правильной версией DLL файлов Windows не может быть используется потому, что окна автоматически определяет его для вас в зависимости от того, совершает ли 32-битное или 64-разрядное приложение. Это, предположительно, проблема для mingw64 , потому что компилятор gcc 64-бит, но msys безнадежно 32-битный.
Но так как я пробовал 32-битные версии, приведенное выше, похоже, не объясняет ошибку . Даже больше, я пробовал грязным способом прокомментировать все звонки GetACP()
, , потому что мне действительно не нравятся кодовые страницы и все, что для моих целей. Как ни странно, компиляция в порядке (на свежий источник только с комментариями GetACP()
), но по-прежнему сообщается об одной и той же ошибке. Я проверил, что libkernel32.a
, libiconv.a
находятся в папке lib
, а также следуйте инструкциям в блоге выше, чтобы скопировать dll из c:\windows\system32
и поместить их в подпапки mingw с соответствующим переименованием. Ошибка связи. Здесь я прекратил взламывать, потратив на это почти два дня без успеха. Я не могу понять, почему весь исходный код не содержит одного вызова функции, и я все еще получаю сообщение об ошибке.
Может ли кто-нибудь объяснить, что могло вызвать эту проблему между gdal и mingw64, и как исправить это?
Кроме того, общий вопрос о mingw64 заключается в том, что он действительно может поддерживать функции posix? Я вижу имена пакетов, такие как x64-4.8.0-release-posix-seh-rev2.7z, но я помню, что люди MinGW сказали , что они никогда не будут поддерживать полный posix.
P.S. Я тестирую это на Windows Server 2008 R2, 64-разрядный.
Update: Полных шагов для создания библиотеки GDAL-1.10.0 под MinGW64 (MinGW-версия) являются:
$./configure
Затем Edit GDALmake.opt, найдите GDAL_ROOT и замените формат привода cygwin на формат dos/mingw, например. Изменение:
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/
Это превосходно. Протестировано с использованием x64-4.8.1-release-posix-seh-rev0 (mingw-builds). Примечание: похоже, что в GDALmake.opt уже есть -liconv. Но, как-то он не был поднят под MinGW64 (за mingw-builds). – tinlyx
Итак, почему эта ошибка возникает? –