2013-05-15 2 views
5

Я пытался построить библиотеку 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/ 

ответ

4

Я случайно столкнулся с той же проблемой. Может быть, это ошибка MinGW или плохие файлы конфигурации, но решение добавить -liconv до конца флагов компоновщика, например, заменить

CONFIG_LIBS = $(GDAL_ROOT)/$(LIBGDAL) 

с

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

в Файл GDALmake.opt (найденный путем поиска в каталоге Mingw для GetACP в файлах).

+0

Это превосходно. Протестировано с использованием x64-4.8.1-release-posix-seh-rev0 (mingw-builds). Примечание: похоже, что в GDALmake.opt уже есть -liconv. Но, как-то он не был поднят под MinGW64 (за mingw-builds). – tinlyx

+0

Итак, почему эта ошибка возникает? –

 Смежные вопросы

  • Нет связанных вопросов^_^