2011-12-27 5 views
6

Voglio impacchettare GDAL e il suo binding JAVA in un plug-in SWT. (P.S. uso GDAL sorso per generare vincolante Java)GDAL JAVA Binding e libreria nativa in un plug-in SWT

Ho tutti i necessari librerie native e voglio comprimerle nel mio plug-in Eclipse di lasciare che altre persone lo usano senza installare GDAL sul proprio computer.

Il problema è che il JAVA Binding (o nativo lib stesso) sarà occhiata necessarie librerie native da PATH (finestra) o LD_LIBRARY_PATH (Linux), invece guardando quelle librerie in una posizione relativa. Inoltre, GDAL cercherà anche alcuni dati di geo definizione necessari dalla variabile di ambiente GDAL_DATA.

Come posso risolvere questi due problemi per creare un plug-in SWT portatile? 1) pacchetto di librerie native specifiche 2) alcune variabili di ambiente look

Sembra che Eclipse non possa risolvere libs dipendenti senza avere PATH impostato. Bundle-NativeCode (vedi sotto) non ha funzionato.

Se provo a chiamare direttamente System.Library ("SomethingNotExist") nel mio plug-in; tanto sono

java.lang.UnsatisfiedLinkError: no SomethingNotExist in java.library.path 

Se chiamo System.Library ("SomethingDoesExist") nel mio plug-in, allora ottengo

java.lang.UnsatisfiedLinkError: SomethingDoesExist.dll: Can't find dependent libraries 

La struttura del file nel mio plug

org.gdal/ 
    + src/ 
    + nativelib/ 
     + linux32/ 
     + ... 
     + linux32/ 
     + ... 
     + win32/ 
     + ... 
     + win64/ 
     + ... 
    + META-INF 
     + MANIFEST.MF 
    + gdal-data/ 
    + gdal.jar 
    + build.properties 

Build.properties per questo plug-in

source.. = src/ 
output.. = bin/ 
bin.includes = META-INF/,\ 
       .,\ 
       gdal.jar,\ 
       gdal-data/,\ 
       nativelib/ 

Il Manifesto per questo plug-in

Manifest-Version: 1.0 
Bundle-ManifestVersion: 2 
Bundle-Name: GDAL 
Bundle-SymbolicName: org.gdal 
Bundle-Version: 1.8.1 
Bundle-NativeCode: 
nativelib/linux32/libgdal.so; 
nativelib/linux32/libgdalconstjni.so; 
nativelib/linux32/libgdaljni.so; 
nativelib/linux32/libogrjni.so; 
nativelib/linux32/libosrjni.so; 
osname=Linux; processor=x86, 
nativelib/linux64/libgdal.so; 
nativelib/linux64/libgdalconstjni.so; 
nativelib/linux64/libgdaljni.so; 
nativelib/linux64/libogrjni.so; 
nativelib/linux64/libosrjni.so; 
osname=Linux; processor=x86_64, 
nativelib/win32/gdal18.dll; 
nativelib/win32/gdalconstjni.dll; 
nativelib/win32/gdaljni.dll; 
nativelib/win32/geos_c.dll; 
nativelib/win32/iconv.dll; 
nativelib/win32/libcurl.dll; 
nativelib/win32/libeay32.dll; 
nativelib/win32/libexpat.dll; 
nativelib/win32/libmysql.dll; 
nativelib/win32/libpq.dll; 
nativelib/win32/libxml2.dll; 
nativelib/win32/ogrjni.dll; 
nativelib/win32/openjpeg.dll; 
nativelib/win32/osrjni.dll; 
nativelib/win32/pdflib.dll; 
nativelib/win32/proj.dll; 
nativelib/win32/spatialite.dll; 
nativelib/win32/sqlite3.dll; 
nativelib/win32/ssleay32.dll; 
nativelib/win32/xerces-c_2_8.dll; 
nativelib/win32/zlib1.dll; 
osname=win32; processor=x86, 
nativelib/win64/ogrjni.dll; 
nativelib/win64/gdal18.dll; 
nativelib/win64/xerces-c_2_8.dll; 
nativelib/win64/libexpat.dll; 
nativelib/win64/libpq.dll; 
nativelib/win64/spatialite.dll; 
nativelib/win64/libmysql.dll;  
nativelib/win64/geos_c.dll; 
nativelib/win64/libcurl.dll; 
nativelib/win64/openjpeg.dll; 
nativelib/win64/iconv.dll; 
nativelib/win64/libeay32.dll; 
nativelib/win64/gdaljni.dll; 
nativelib/win64/osrjni.dll; 
nativelib/win64/gdalconstjni.dll; 
nativelib/win64/libxml2.dll; 
nativelib/win64/pdflib.dll; 
nativelib/win64/proj.dll; 
nativelib/win64/sqlite3.dll; 
nativelib/win64/ssleay32.dll; 
nativelib/win64/zlib1.dll; 
osname=win32; processor=x86_64 
Bundle-ClassPath: gdal.jar, 
., 
gdal-data/ 
Export-Package: org.gdal, 
org.gdal.gdal, 
org.gdal.gdalconst, 
org.gdal.ogr, 
org.gdal.osr 
Bundle-RequiredExecutionEnvironment: JavaSE-1.6 

+0

Qual è esattamente il problema (quello che gli errori sono segnalati da chi)? OSGi caricherà le DLL dal tuo plugin in base alla sezione 'Bundle-NativeCode', quindi * JAVA Binding (o lib nativa stessa) cercherà le librerie native necessarie da PATH * non è il caso. –

+0

@Martti: davvero? Penso che il codice nativo tenta di caricare le librerie rilevanti da PATH e cerca alcuni dati di configurazione da un altro percorso di variabile d'ambiente definito. Messaggio di errore: [[Caricamento libreria nativa fallito. java.lang.UnsatisfiedLinkError: ogrjni.dll: Impossibile trovare le librerie dipendenti]] – elgcom

+0

Sì, ** le librerie native ** si stanno caricando dal PERCORSO.Il punto che stavo cercando di fare è che questo non ha nulla a che fare con Eclipse e Java, ma con la normale risoluzione della lib di qualsiasi programma. –

risposta

Problemi correlati