Bonjour à tous.
Je galère depuis des heures sur un problème d'une simplicité enfantine (en tout cas pour moi qui fait du C++).
Je travaille sous Eclipse / JRE 7
J'utilise un .jar compilé pour utiliser une dll native via JNI.
Ce .jar c'est gdal.jar un wrapper JNI autour de gdal (produit cartographique).
Jusque là, tout va bien. Sauf que le gdal.jar et toutes ses dépendances (dlls) ne sont pas situés à la racine du projet mais correctement ordonés dans un répertoire "lib". Rien de bien exceptionnel ... sauf pour java !
En effet, si j'ajoute le .lib au classpath via (repRootJar est le chemin root en absolu, calculé précedemment) :
je peux charger mes dlls avec "System.loadLibrary("expat_ogdi3.2.0.beta2");" par exemple. cette dll est une des dlls chargées par gdal (dépendance).
Code : Sélectionner tout - Visualiser dans une fenêtre à part JavaLibraryPath.addToJavaLibraryPath(new File(repRootJar,"lib/"));
Ceci fonctionne pour toutes les dlls sauf que l'une d'entre elle (driver JPeg2000) a une dépendance sur le runtime .net et elle provoque une exception au chargement.
On oublie, on supprime le loadLibrary...
Et on charge directement le jar via l'appel de la méthode gdal.AllRegister();
et là : java.lang.UnsatisfiedLinkError: D:\.......xxxxxxx......03-source\lib\gdaljni.dll: Can't find dependent libraries
En effet, le programme charge gdal.jar qui lui a besoin des dlls. Les dlls sont chargée d'abord dans le CurrentWorkingDirectory qui n'est pas "lib" mais le répertoire racine du projet, résultat il trouve pas les dépendances.
-> Recherche de solution. A priory changer le current working directory ne peut pas être fait en java.
-> placer toutes mes dlls, mes .jar et tout le toutim à la racine du projet histoire que ce soit bien crade (sinon ça marche super bien).
-> Appeler la JVM avec -cp "D:\......\03-source\lib"
-> Appeler la JVM avec -Djava.class.path="D:\.......\03-source\lib"
Rien ne fonctionne si les dlls (et le gdal.jar) sont situés dans le répertoire lib.
La seule façon que j'ai trouvée c'est sous Eclipse, modifier le Working Directory (on en revient toujours à celui-là).
Et visiblement impossible de le faire dans le programme.
Surtout que les chemins, une fois déployé chez le client ne sont plus les mêmes et le .jar est encapsulé dans un exécutable avec launch4j (j'en suis pas là).
Voilà, ce problème devrait être classique mais impossible de trouver une solution propre permettant par exemple de changer le current working folder par programme ou modifier le classpath qui modifie en fait le PATH interne où le .jar va pouvoir aller chercher ses dépendances...
Vous avez une idée ?
Partager