Comment faire pour résoudre un UnsatisfiedLinkError (ne Peut pas trouver de bibliothèques dépendantes) dans un JNI projet

Je suis en train de travailler sur un projet en Java qui utilise la JNI. La JNI appelle une bibliothèque personnalisée que j'ai écrit moi-même, disons mylib.dll, et qui dépend de la 3e partie de la bibliothèque, libsndfile-1.dll.

Quand je lance mon programme il plante avec 

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

J'ai cherché sur ce site (et d'autres) et j'en ai essayé un certain nombre de corrections:

  1. J'ai couru dependency walker. DW a donné un couple de mises en garde -- que deux bibliothèques requises par libsndfile, MPR.DLL et SHLWAPI.DLL, avait "en suspens importations" -- mais le DW FAQ dit que ces avertissements peut être ignoré en toute sécurité.

  2. J'ai corrigé les noms de méthode dans mylib.dll comme l'a suggéré ici. La méthode noms avaient, en quelque sorte obtenu mutilé par le compilateur, mais j'ai ajouté de l'éditeur de liens et de drapeaux, la méthode dll, les noms correspondent à ceux de mon jni fichier d'en-tête exactement.

  3. J'ai mis toutes ces Dll dans le même répertoire -- le même répertoire que le .jar qui les appelle, pour s'assurer qu'ils sont sur le droit CHEMIN.

Pas de dés.

Quelqu'un a une idée de ce qui se passe?

Je suis en train de faire mon développement dans Visual Studio 2010 sur un MacBook pro (via Parallels). Je suis en train de faire mes tests sous Windows XP sur un portable toshiba.

  • avez-vous mis -Djava.de la bibliothèque.chemin d'accès ?
  • Je n'ai pas, en fait, parce que je ne suis pas à lancer le programme depuis la ligne de commande. Je suis en train d'écrire une bibliothèque pour le Traitement de (processing.org), et le Traitement est responsable pour le lancement de mon code. J'ai vérifié la bibliothèque java chemin d'accès lors de l'exécution, cependant, et le dossier contenant mes Dll qui est sur elle.
  • Comme je l'ai dit, toutes les Dll dans le même dossier, à côté de mon .fichier jar. Donc, je ne pense pas que le problème est qu'ils ne sont pas sur le chemin. Mais merci quand même.
  • Sur Windows, nous avons eu à mettre .les fichiers dll dans le [JRE]\bin (même lieu où java.exe, etc. sont) pour obtenir Java pour les voir automatiquement sans avoir à nettoyer avec des options de ligne de commande ou des variables d'environnement.
  • Hmm... ok, j'ai essayé de mettre toutes mes .dll dans [JRE]\bin. Cela fonctionne!
  • Voir où . est dans votre PATH, par rapport à d'autres répertoires (JRE, Windows, etc...). L'une des premières entrées pourraient fournir une version d'une bibliothèque qui est incompatible avec celles que vous essayez de charger à partir du répertoire courant. Le déplacement . de loin mon CHEMIN a fait l'affaire pour moi, et m'a sauvé d'avoir à polluer l'environnement JRE répertoire avec mes bibliothèques.

InformationsquelleAutor dB' | 2011-05-23
  1. 44

    Je suis sûr que le chemin de la classe et de la bibliothèque partagée chemin de recherche ont peu à voir les uns avec les autres. Selon La JNI Livre (qui certes est vieux), sur Windows si vous n'utilisez pas le java.library.path système de propriété, la DLL doit être dans le répertoire de travail actuel ou dans un répertoire listé dans le Windows PATH variable d'environnement.

    Mise à jour:

    Ressemble Oracle a supprimé le fichier PDF à partir de son site web. J'ai mis à jour le lien ci-dessus pour pointer vers une instance de la PDF de la vie à l'Université du Texas - Arlington.

    Vous pouvez également lire Oracle de la version HTML de la JNI Spécification. Qui vit dans Java 8 section du site web de Java et donc, espérons-le, sera autour pendant un certain temps.

    Mise à jour 2:

    Au moins dans Java 8 (je n'ai pas vérifié les versions antérieures), vous pouvez le faire:

    java -XshowSettings:properties -version

    pour trouver la bibliothèque partagée chemin de recherche. Recherchez la valeur de la java.library.path propriété dans cette sortie.

    • Ouais, CLASSPATH n'est pas utilisé du tout. Je ne suis pas sûr de la cwd est utilisé, que ce soit. java.library.path ou tout simplement PATH fonctionne. @dB", l'endroit où vous êtes maintenant, c'est mal.
    • Merci beaucoup les gars! Je pense qu'une partie du problème ici, c'est une confusion de ma part entre la variable d'environnement PATH, java.de la bibliothèque.chemin d'accès et le chemin de classe java. Tout cela a plus de sens maintenant.
    • S'il vous plaît pouvez-vous expliquer comment les avez-vous surmontées par le biais de ce problème?
    • Je pense que si vous ajoutez le répertoire où les bibliothèques sont à la variable d'environnement "path" et redémarrez l'invite de commande ou d'un terminal, il devrait résoudre le problème. Java cherche des pots en vertu de classpath, et les bibliothèques en vertu de chemin.
    • Basé sur cette réponse, il semble que la commande de mise à Jour 2 est disponible depuis au moins la version Java 7: stackoverflow.com/a/8472139/901641
    InformationsquelleAutor QuantumMechanic
  2. 17

    Je veux ce cas intéressant, après avoir essayé toutes les méthodes mentionnées ci-dessus, l'erreur est toujours là. La chose étrange est qu'il fonctionne sur un ordinateur Windows 7, mais sur Windows XP, il n'est pas. Puis-je utiliser dependency walker et trouvés sur le Windows XP il n'y a pas de VC++ Runtime comme ma dll en condition. Après l'installation de VC++ Runtime package ici il fonctionne comme un charme. La chose qui m'a dérangé est qu'il n'arrête pas de raconter ne Peut pas trouver de bibliothèques dépendantes, alors qu'intuitivement la JNI dépendante de la dll est-il, cependant, il s'avère finalement la JNI dll dépendante nécessite un autre dépendant de dl. J'espère que cette aide.

    • Le message est correct mais trompeur dans ce cas. J'ai eu les deux VC++ runtime manquant sur la zone test et la bibliothèque compilée en mode de débogage (en fonction de non-redistribuable de débogage de logiciels d'exécution). Dependency Walker a été d'une grande aide pour celui-ci.
    • eu le même problème à l'aide de jnetpcap-bibliothèque. la dépendance winpcap n'était pas installé sur la machine de plus et le message d'exception est trompeur
    • im pensant que ce pourrait être mon cas .
    InformationsquelleAutor longbkit
  3. 13

    Vous avez besoin pour charger votre JNI bibliothèque.

    Système.loadLibrary charge la DLL à partir de la JVM chemin du JDK (bin path).

    Si vous souhaitez charger explicitement un fichier avec un chemin d'accès, à l'utilisation Système.charge()

    Voir aussi: La différence entre le Système.load() et du Système.loadLibrary en Java

    InformationsquelleAutor Yochai Timmer
  4. 5

    Veuillez vérifier votre chemin de la bibliothèque qui est bon ou pas. Bien sûr, vous pouvez utiliser le code suivant pour vérifier votre bibliothèque de chemin de chemin:
    System.out.println(System.getProperty("java.library.path"));

    Vous pouvez désigner le java.de la bibliothèque.chemin lors du lancement d'une application Java:

    java -Djava.library.path=path ...
    InformationsquelleAutor caopeng
  5. 4

    N'ont problème identique avec sur la machine XP lors de l'installation de javacv et opencv en combinaison avec Eclipse. Il s'est avéré qu'il me manquait les fichiers suivants:

    • msvcp100.dll
    • msvcr100.dll

    Une fois que ces ont été installés, le projet compilé et exécuté sur OK.

    • J'ai le même problème qui disparaissent après l'installation de "Microsoft Visual C++ 2010 SP1 Redistributable Package (x86)"
    InformationsquelleAutor Rob van Riswick
  6. 3

    Si vous chargez une version 32 bits de votre fichier dll avec une version 64 bits JRE que vous pourriez avoir ce problème. Cela a été mon cas.

    • C'est probablement aussi mon cas, si quelqu'un est au courant de solutions connues, je serais intéressé; à l'exception du chargement d'une version 64 bits, comme dans ce cas, le processus n'est pas une dll, mais chromedriver.exe, le Sélénium pilote pour Chrome, qui, autant que je peux dire est livré uniquement dans la version 32 bits.
    InformationsquelleAutor EFalco
  7. 2
    • Réponse courte: pour des "impossible de trouver la bibliothèque dépendante" d'erreur, vérifiez votre $PATH (correspond au point 3 ci-dessous)
    • Réponse longue:
      1. Pur monde java: jvm utilise le "Classpath" pour trouver les fichiers de classe
      2. JNI mondiale (java/native limite): jvm utilise java.de la bibliothèque.chemin d'accès" (qui, par défaut, $PATH) pour trouver les dll
      3. pur natif monde: en code natif utilise $CHEMIN d'accès pour charger d'autres dll
    InformationsquelleAutor user2038596
  8. 2

    J'ai trouvé un grand article par quelques amis à keepsafe qui est passé par la même chose que j'ai fait. Il a travaillé pour moi, alors j'espère qu'il vous aide ainsi! À lire si vous êtes intéressé ( Les Dangers de Chargement de Bibliothèques Natives sur Android ), ou simplement utiliser

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

    et remplacer 

    System.loadLibrary("myLibrary");

    avec 

    ReLinker.loadLibrary(context, "mylibrary");
    InformationsquelleAutor rhysl
  9. 1

    J'ai utilisé exactement le même problème, et il a enfin été résolu.

    J'ai mis toutes les Dll dépendantes dans le même dossier où mylib.dll a été stocké et assurez-vous que le Compilateur JAVA pourrait le trouver (si il n'y a pas de mylib.dll dans la compilation chemin, il y aurait une erreur de déclaration de cela lors de la compilation). La chose importante que vous devez noter est que vous devez assurez-vous que tous les dépendants libs sont de la même version avec mylib.dll par exemple, si votre mylib.dll est version, alors vous devriez également mettre la version de tous ses dépendants libs là.

    Espère que cela peut aider d'autres personnes qui ont rencontré le même problème.

    InformationsquelleAutor Steven Peng
  10. 1

    J'ai eu le même problème, et j'ai essayé tout ce qui est posté ici pour le réparer, mais aucun n'a fonctionné pour moi.
    Dans mon cas, je suis en utilisant Cygwin pour compiler la dll. Il semble que la JVM essaie de trouver le JRE Dll dans le virtuel Cygwin chemin.
    J'ai ajouté la Cygwin virtuel du chemin d'accès au répertoire JRE Dll et cela fonctionne maintenant.
    J'ai fait quelque chose comme:

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

    InformationsquelleAutor estebanuri
  11. 1

    Dans ma situation, j'ai essayé de lancer un service web java Tomcat 7 par l'intermédiaire d'un connecteur dans Eclipse. L'application a bien fonctionné quand j'ai déployé le fichier war à une instance de Tomcat 7 sur mon ordinateur portable. L'application nécessite un jdbc de type 2 de pilote pour "IBM DB2 9.5". Pour une raison étrange, le connecteur dans Eclispe ne pouvait pas voir ou utiliser les chemins d'accès dans IBM DB2 variables d'environnement, pour atteindre les fichiers dll installé sur mon ordinateur portable comme le ccc client. Le message d'erreur dit qu'il n'a pas trouvé les db2jcct2 fichier dll ou il n'a pas trouvé les bibliothèques dépendantes pour que le fichier dll. En fin de compte, j'ai supprimé le connecteur et l'a reconstruit. Puis il a travaillé correctement. Je suis l'ajout de cette solution ici que de la documentation, parce que je n'ai pas réussi à trouver cette solution spécifique de n'importe où ailleurs.

    InformationsquelleAutor bwfrieds
  12. 0

    La création de bibliothèque statique a fonctionné pour moi, la compilation à l'aide g++ -static. Il regroupe les bibliothèques dépendantes ainsi que le construire.

    InformationsquelleAutor Caesar
  13. -2
    1. Aller à http://tess4j.sourceforge.net/usage.html et cliquez sur Visual C++ Redistributable for VS2012
    2. Télécharger et de l'exécuter VSU_4\vcredist_x64.exe ou VSU_4\vcredist_x84.exe selon la configuration de votre système
    3. Mettre votre dll fichiers à l'intérieur de la lib dossier, le long de avec d'autres bibliothèques (par exemple \lib\win32-x86\your dll files).
    InformationsquelleAutor Pratik Varpe