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/
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
Quindi, perché si verifica questo errore? –