2013-05-15 11 views
5

stavo cercando di costruire gdal-1.10.0 (http://trac.osgeo.org/gdal/wiki/DownloadSource) utilizzando mingw64 (da http://sourceforge.net/projects/mingwbuilds/files/host-windows/ x64-4.8.0-release-POSIX-seh-rev2.7z). Ho compilato gdal-1.10.0 con la versione standard MinGW (32-bit) senza problemi.errore di collegamento con GetACP sotto mingw64 (mingw-costruisce)

Il motivo devo passare a mingw64 è che lo standard della distribuzione MinGW 32 bit non supporta C++ 11 caratteristiche come std::thread, e (sospetto) altre caratteristiche come bene. Ma ottengo un errore durante il collegamento alla fine mi dice qualcosa a proposito

undefined reference to '__imp_GetACP' 

(o un nome decorato diverso se io uso la variante a 32 bit da mingw64/mingw-build). A proposito, ho provato diverse versioni di mingw64, tra cui 64-bit, 32-bit, seh, sjlj, ma tutti hanno dato lo stesso errore su GetACP().

ho fatto un certo lavoro e hanno trovato alcune istruzioni per un simile compito compilazione: http://www.gaia-gis.it/spatialite-3.0.0-BETA/mingw64_how_to.html#env Secondo il sito web di cui sopra, sembra che suggeriscono il problema ha a che fare con WOW64 e la versione corretta del file DLL di Windows non può essere utilizzato perché Windows lo determina automaticamente in base all'applicazione a 32 bit o a 64 bit che effettua la chiamata. Questo è presumibilmente un problema per mingw64 perché il compilatore gcc è a 64 bit ma msys è irrimediabilmente a 32 bit.

Ma poiché ho provato anche le versioni a 32 bit, quanto sopra non sembra spiegare l'errore . Ancora di più, ho cercato in modo sporco di commentare tutte le chiamate a GetACP(), perché non mi interessa davvero le code page e tutto ciò per i miei scopi. Stranamente, la compilazione è OK (su una nuova fonte solo con il commento di GetACP()), ma lo stesso errore di collegamento è ancora riportato. Ho verificato che libkernel32.a, libiconv.a sono nella cartella lib e ho seguito le istruzioni nel blog in alto per copiare dll da c:\windows\system32 e inserirli in sottocartelle mingw con la corretta ridenominazione. L'errore di collegamento rimane. È qui che ho smesso di hackerare dopo aver trascorso quasi due giorni senza successo. Non riesco a capire perché l'intero codice sorgente non contenga una singola chiamata alla funzione e sto ancora ricevendo l'errore di collegamento.

Qualcuno può spiegare che cosa potrebbe aver causato questo problema tra gdal e mingw64, e come risolverlo?

Inoltre, una domanda generale su mingw64 è che è realmente in grado di supportare le funzioni posix ? Vedo nomi di pacchetti come x64-4.8.0-release-posix-seh-rev2.7z, ma ricordo che il popolo MinGW ha detto che non supporteranno mai full posix.

P.S. Lo sto testando su Windows Server 2008 R2, 64-bit.


Aggiornamento: I passaggi completi per la costruzione di gdal-1.10.0 sotto MinGW64 (mingw-build) sono:

$./configure 

Poi, Modifica GDALmake.opt, trova GDAL_ROOT e sostituisci il formato dell'unità cygwin con il formato dos/mingw, ad es. Cambio:

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

a

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

Sostituire

CONFIG_LIBS = $(GDAL_ROOT)/$(LIBGDAL) 

con

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

Infine,

012.351.641,061 mila
$ make && make install && cp apps/*.exe /usr/local/bin/ 

risposta

4

Ho riscontrato accidentalmente lo stesso problema. forse questo è un bug MinGW o file di configurazione cattivi, ma la soluzione è quella di aggiungere -liconv al fine di bandiere linker, per esempio, sostituire

CONFIG_LIBS = $(GDAL_ROOT)/$(LIBGDAL) 

con

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

in File GDALmake.opt (trovato ricercando la directory Mingw per GetACP nei file).

+0

Questo è eccellente. Testato usando x64-4.8.1-release-posix-seh-rev0 (mingw-builds). Nota: sembra che ci fosse già un -liconv in GDALmake.opt. Ma, in qualche modo non è stato raccolto sotto MinGW64 (per mingw-build). – tinlyx

+0

Quindi, perché si verifica questo errore? –

Problemi correlati