Come risolvere un errore UnsatisfiedLinkError (impossibile trovare le librerie dipendenti) in un progetto JNI

Sto lavorando a un progetto Java che utilizza JNI. JNI chiama una libreria personalizzata che ho scritto io stesso, diciamo mylib.dll, e che dipende da una libreria di terze parti, libsndfile-1.dll.

Quando eseguo il mio programma si blocca con

java.lang.UnsatisfiedLinkError:  C:\...path...\mylib.dll: Can't find dependent libraries.

Ho cercato in questo sito (e altri) e ho provato una serie di correzioni:

1. Ho eseguito il walker delle dipendenze. DW ha fornito un paio di avvertimenti - che due librerie richieste da libsndfile, MPR.DLL e SHLWAPI.DLL, avevano "importazioni non risolte" - ma la FAQ DW ha detto che questi avvertimenti potevano essere tranquillamente ignorati.

2. Ho corretto i nomi dei metodi in mylib.dll, come suggerito qui . I nomi dei metodi erano stati in qualche modo alterati dal compilatore, ma ho aggiunto i flag del linker ei nomi dei metodi dll ora corrispondono esattamente a quelli nel mio file di intestazione jni.

3. Metto tutte queste DLL nella stessa directory, la stessa directory del .jar che le chiama, per assicurarmi che siano sul PERCORSO corretto.

Niente da fare.

Qualcuno ha idea di cosa stia succedendo?

Sto sviluppando in Visual Studio 2010 su un MacBook pro (tramite Parallels). Sto eseguendo i test in Windows XP su un laptop toshiba.

Sono abbastanza sicuro che il percorso di classe e il percorso di ricerca della libreria condivisa abbiano poco a che fare l'uno con l'altro. Secondo The JNI Book (che certamente è vecchio), su Windows se non si utilizza la java.library.pathproprietà di sistema, la DLL deve essere nella directory di lavoro corrente o in una directory elencata nella PATHvariabile di ambiente Windows .

Aggiornare:

Sembra che Oracle abbia rimosso il PDF dal suo sito web. Ho aggiornato il collegamento sopra per indicare un'istanza del PDF che vive presso l'Università del Texas - Arlington.

Inoltre, è anche possibile leggere la versione HTML di Oracle della specifica JNI . Si trova nella sezione Java 8 del sito Web Java e quindi si spera che rimarrà in giro per un po '.

Aggiornamento 2:

Almeno in Java 8 (non ho controllato le versioni precedenti) puoi fare:

java -XshowSettings:properties -version

per trovare il percorso di ricerca della libreria condivisa. Cerca il valore della java.library.pathproprietà in quell'output.

Voglio informare questo caso interessante, dopo aver provato tutto il metodo sopra, l'errore è ancora lì. La cosa strana è che funziona su un computer Windows 7, ma su Windows XP non lo è. Quindi uso il walker delle dipendenze e ho scoperto che su Windows XP non esiste il runtime VC ++ come requisito della dll. Dopo aver installato il pacchetto Runtime VC ++ qui funziona come un fascino. La cosa che mi ha disturbato è che continua a dire Impossibile trovare librerie dipendenti, mentre intuitivamente la DLL dipendente da JNI è presente, tuttavia alla fine risulta che la DLL dipendente da JNI richiede un altro DL dipendente. Spero che possa aiutare.

Devi caricare la tua libreria JNI.

System.loadLibrary carica la DLL dal percorso JVM (percorso bin JDK).

Se vuoi caricare un file esplicito con un percorso, usa System.load ()

Vedi anche: Differenza tra System.load () e System.loadLibrary in Java

Verifica che il percorso della tua libreria sia corretto o meno. Naturalmente, puoi utilizzare il seguente codice per controllare il percorso del percorso della tua libreria: System.out.println(System.getProperty("java.library.path"));

È possibile nominare java.library.path quando si avvia un'applicazione Java:

java -Djava.library.path=path ...

Se carichi una versione a 32 bit della tua dll con un JRE a 64 bit potresti avere questo problema. Questo è stato il mio caso.

Ha avuto lo stesso problema con la macchina XP durante l'installazione javacve opencvin combinazione con Eclipse. Si è scoperto che mi mancavano i seguenti file:

• msvcp100.dll
• msvcr100.dll

Una volta installati, il progetto è stato compilato ed è stato eseguito correttamente.

• Risposta breve: per l'errore "impossibile trovare la libreria dipendente", controlla il tuo $ PATH (corrisponde al punto 3 di seguito)
• Risposta lunga:
  1. Pure java world: jvm usa "Classpath" per trovare i file di classe
  2. JNI world (java / native boundary): jvm utilizza "java.library.path" (il cui valore predefinito è $ PATH) per trovare le dll
  3. puro mondo nativo: il codice nativo utilizza $ PATH per caricare altre dll

Ho trovato un ottimo articolo di alcuni amici di Keepsafe che ha ripetuto la stessa cosa che ho fatto io. Ha funzionato per me, quindi spero che aiuti anche te! Dai una lettura se sei interessato ( I pericoli del caricamento di librerie native su Android ) o usa semplicemente

compile 'com.getkeepsafe.relinker:relinker:1.2.3'

e sostituire

System.loadLibrary("myLibrary");

con

ReLinker.loadLibrary(context, "mylibrary");

Avevo esattamente lo stesso problema e alla fine è stato risolto.

Metto tutte le DLL dipendenti nella stessa cartella in cui è stato memorizzato mylib.dll e mi assicuro che il compilatore JAVA possa trovarlo (se non c'è mylib.dll nel percorso di compilazione, ci sarebbe un errore che lo segnala durante la compilazione). La cosa importante che devi notare è che devi assicurarti che tutte le librerie dipendenti siano della stessa versione di mylib.dll, ad esempio se la tua mylib.dll è la versione di rilascio, dovresti anche inserire la versione di rilascio di tutte le sue librerie dipendenti lì .

Spero che questo possa aiutare altri che hanno riscontrato lo stesso problema.

Ho avuto lo stesso problema e ho provato tutto ciò che è pubblicato qui per risolverlo, ma nessuno ha funzionato per me. Nel mio caso sto usando Cygwin per compilare la dll. Sembra che JVM cerchi di trovare le DLL JRE nel percorso virtuale di Cygwin. Ho aggiunto il percorso della directory virtuale di Cygwin alle DLL di JRE e ora funziona. Ho fatto qualcosa come:

SET PATH = "/ cygdrive / c / Program Files / Java / jdk1.8.0_45";% PATH%

Nella mia situazione, stavo cercando di eseguire un servizio Web Java in Tomcat 7 tramite un connettore in Eclipse. L'app ha funzionato bene quando ho distribuito il file war su un'istanza di Tomcat 7 sul mio laptop. L'app richiede un driver jdbc di tipo 2 per "IBM DB2 9.5". Per qualche strana ragione il connettore in Eclispe non poteva vedere o utilizzare i percorsi nelle variabili d'ambiente IBM DB2, per raggiungere i file dll installati sul mio laptop come client jcc. Il messaggio di errore indicava che non era riuscito a trovare il file dll db2jcct2 o non era riuscito a trovare le librerie dipendenti per quel file dll. Alla fine, ho eliminato il connettore e l'ho ricostruito. Quindi ha funzionato correttamente. Sto aggiungendo questa soluzione qui come documentazione, perché non sono riuscito a trovare questa soluzione specifica altrove.

La creazione della libreria statica ha funzionato per me, la compilazione utilizzando g++ -static. Raggruppa le librerie dipendenti insieme alla build.

installazione di Microsoft Visual C ++ 2010 SP1 Redistributable Risolto

posizionare le DLL richieste nella cartella e impostare il percorso della cartella nella variabile di ambiente PATH. assicurati che la variabile PATH dell'ambiente aggiornata sia riflessa.

Stavo affrontando lo stesso problema con la libreria ffmpeg dopo aver unito due progetti Android come un unico progetto.

In realtà il problema stava arrivando a causa di due diverse versioni della libreria ffmpeg ma erano caricate con gli stessi nomi in memoria. Una libreria è stata collocata in JNiLibs mentre l'altra era all'interno di un'altra libreria utilizzata come modulo. Non sono stato in grado di modificare il codice del modulo poiché era di sola lettura, quindi ho rinominato quello utilizzato nel mio codice in ffmpegCamera e l' ho caricato in memoria con lo stesso nome.

System.loadLibrary("ffmpegCamera");

Questo ha risolto il problema e ora entrambe le versioni delle librerie vengono caricate bene come nome separato e ID processo in memoria.

Durante la chiamata System.loadLibrary(), la JVM guarderà sujava.library.path tua libreria nativa. Tuttavia, se quella libreria nativa dichiara delle dipendenze da altre librerie native, il sistema operativo avrà il compito di trovare quelle dipendenze della libreria nativa.

Dal momento che il sistema operativo non ha il concetto di java.library.path, non vedrà alcuna directory inserita in java.library.path. Invece, cercherà solo nelle directory sulla variabile d'ambiente PATH del sistema operativo. Questo va benissimo se la dipendenza della libreria nativa è una libreria nativa del sistema operativo perché si troverà nel PATH. Tuttavia, se la dipendenza della libreria nativa è una libreria nativa creata dall'utente o da qualcun altro, non verrà trovata nel PERCORSO a meno che non la si posizioni lì. Questo comportamento è strano, inaspettato e non ben documentato, ma è documentato nel tracciatore di problemi di OpenJDK qui . Puoi anche trovare un'altra risposta StackOverflow che rafforza questa spiegazione, qui .

Quindi, hai un paio di opzioni. È possibile caricare ciascuna libreria nativa nell'ordine di dipendenza corretto utilizzando System.loadLibrary()oppure modificare il PERCORSO per includere le directory in cui sono archiviate le librerie native.

1. Vai a http://tess4j.sourceforge.net/usage.html e fai clic suVisual C++ Redistributable for VS2012
2. Scaricalo ed eseguilo VSU_4\vcredist_x64.exeo in VSU_4\vcredist_x84.exebase alla configurazione del tuo sistema
3. Metti i tuoi dllfile all'interno della libcartella, insieme alle altre tue librerie (ad esempio \lib\win32-x86\your dll files).