2013-05-15 31 views
5

Tôi đã cố gắng xây dựng GDAL-1.10.0 (http://trac.osgeo.org/gdal/wiki/DownloadSource) sử dụng mingw64 (từ http://sourceforge.net/projects/mingwbuilds/files/host-windows/ x64-4.8.0-release-posix-seh-rev2.7z). Tôi đã biên soạn gdal-1.10.0 theo phiên bản chuẩn MinGW (32 bit) không có vấn đề gì.liên kết lỗi với GetACP dưới mingw64 (mingw-xây dựng)

Lý do tôi phải chuyển sang mingw64 là phân phối chuẩn 32 bit MinGW không hỗ trợ C++ 11 tính năng như std::thread và (tôi nghi ngờ) các tính năng khác là . Nhưng tôi nhận được một lỗi liên kết cuối cùng nói với tôi điều gì đó về

undefined reference to '__imp_GetACP' 

(hoặc một tên trang trí khác nhau nếu tôi sử dụng các biến thể 32-bit từ mingw64/mingw-xây dựng). BTW, tôi đã thử các phiên bản khác nhau của mingw64, bao gồm 64 bit, 32 bit, seh, sjlj, nhưng tất cả đều có cùng lỗi về GetACP().

tôi đã làm một số bài tập về nhà và phát hiện một số hướng dẫn cho một công việc biên soạn tương tự: http://www.gaia-gis.it/spatialite-3.0.0-BETA/mingw64_how_to.html#env Theo trang web trên, có vẻ như họ đề nghị các vấn đề đã làm với WOW64 và đúng phiên bản của file windows dll không thể được sử dụng vì cửa sổ sẽ tự động xác định nó cho bạn tùy thuộc vào việc ứng dụng 32 bit hoặc 64 bit có thực hiện cuộc gọi hay không. Điều này được cho là một vấn đề đối với mingw64 vì trình biên dịch gcc là 64 bit nhưng msys là vô vọng 32-bit.

Nhưng kể từ khi tôi thử phiên bản 32 bit, điều trên dường như không giải thích được lỗi. Thậm chí nhiều hơn, tôi đã thử một cách bẩn thỉu để nhận xét tất cả các cuộc gọi đến GetACP(), vì tôi không thực sự quan tâm đến các trang mã và tất cả những gì cho mục đích của tôi. Kỳ lạ, biên dịch là OK (trên một nguồn mới chỉ với nhận xét của GetACP()), nhưng lỗi liên kết tương tự vẫn được báo cáo. Tôi đã kiểm tra rằng libkernel32.a, libiconv.a nằm trong thư mục lib và cũng làm theo hướng dẫn trong blog ở trên để sao chép dll ra khỏi c:\windows\system32 và đặt chúng trong các thư mục con mingw với cách đổi tên thích hợp. Lỗi liên kết vẫn còn. Đây là nơi tôi ngừng hack sau khi trải qua gần hai ngày về điều này mà không thành công. Tôi không thể hiểu tại sao toàn bộ mã nguồn không chứa một cuộc gọi duy nhất đến hàm và tôi vẫn nhận được lỗi liên kết.

Bất cứ ai có thể giải thích những gì có thể đã gây ra vấn đề này giữa gdal và mingw64, và cách khắc phục sự cố?

Ngoài ra, một câu hỏi chung về mingw64 là nó thực sự có thể hỗ trợ các hàm posix ? Tôi thấy tên gói chẳng hạn như x64-4.8.0-release-posix-seh-rev2.7z, nhưng tôi nhớ rằng những người MinGW đã nói họ sẽ không bao giờ hỗ trợ toàn bộ posix.

P.S. Tôi đang thử nghiệm tính năng này trên Windows Server 2008 R2, 64 bit.


Cập nhật: Các bước hoàn chỉnh để xây dựng GDAL-1.10.0 dưới MinGW64 (mingw-xây dựng) là:

$./configure 

Sau đó, Sửa GDALmake.chọn, Tìm GDAL_ROOT và thay thế định dạng ổ đĩa Cygwin bằng định dạng dos/mingw, ví dụ: Thay đổi:

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

để

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

Thay

CONFIG_LIBS = $(GDAL_ROOT)/$(LIBGDAL) 

với

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

Cuối cùng,

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

Trả lời

4

Tôi đã vô tình gặp phải vấn đề tương tự. Có lẽ đây là một lỗi MinGW hoặc các tập tin cấu hình xấu, nhưng giải pháp là để thêm -liconv đến hết cờ mối liên kết, ví dụ, thay thế

CONFIG_LIBS = $(GDAL_ROOT)/$(LIBGDAL) 

với

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

trong Tệp GDALmake.opt (tìm thấy bằng cách tìm kiếm thư mục Mingw cho GetACP trong tệp).

+0

Điều này thật tuyệt vời. Thử nghiệm bằng cách sử dụng x64-4.8.1-release-posix-seh-rev0 (mingw-builds). Lưu ý: có vẻ như đã có một -liconv trong GDALmake.opt. Nhưng, bằng cách nào đó nó đã không được chọn dưới MinGW64 (mỗi mingw-xây dựng). – tinlyx

+0

Vì vậy, tại sao lỗi này xảy ra? –

Các vấn đề liên quan