Version imprimable
Bonjour
Je suis sous Open Suse 64 bits. J'ai un jar qui a été à compilé sur cette machine et avec ce système d'exploitation, java est fourni par le jdk1.7.0_21.
Je veux utiliser sous Netbeans ce jar, mais il me dit qu'il ne peut le charger : en-tête ELF invalide (possible cause : endianness mismatch) .
Que peut-on faire ?
Merci
Quelle version de NetBeans ?
Installé comment ? (de manière individuelle avec son propre JDK ou sur le JDK existant)
Utilisez-vous NetBeans sur la même plateforme, ou sous une autre, voir dans un MV ?
en-tête elf invalide se produit quand on veux charger une application native, pas une application java. T'es sur de lancer ton jar avec java et que tu n'a pas plutot mis sont flag exécutable à true pour ensuite demander au système de le charger "tel quel" ?
Je voudrais utiliser "jpl.jar" qui est créé lorsque je compile les sources de swi-prolog sous Open Suse.
La version de NetBeans est la 7.3 installée avec son propre jdk et j'ai installé le jre java dans la foulée. C'est bien sur la même plate-forme.
Je connais très peu java et encore moins NetBeans.
Lorsque je mets jpl.jar dans le java.library.path il me dit qu'il n'y a pas de jpl.
Ce que je comprends pas, c'est que je n'ai aucun problème de compilation pour le code, les fonctions du jar utilisées sont compilées sans problème, c'est à l'exécution que ça plante.
si jpl utilise des librairies natives, java.library.path dois contenir le dossier où se trouvent les .so.
Le jar, quand à lui, dois être inclu au classpath (ce que fait automatiquement netbeans si tu lance ton application depuis netbeans).
Le invalid elf pourrais provenir du .so que tu essaierais de charger. Tu pourrais nous donners la stacktrace complete de l'erreur?
Merci pour la réponse.
Je donnerai le stack trace en fin de semaine, là je pars et je vais être absent quelques jours.
Ok,
Je ne voudrai pas vous induire en erreur, mais votre erreur provient à mon sens d'un défaut de format de fichier, au niveau système de fichiers. Comme si votre code cherchait à ouvrir un fichier (64bits) alors qu'il s'agirait d'un fichier (32bits). Cela doit probablement être lié aux librairies système dont parle Tchize. Je n'y connais pas grand chose mais en fouinant sur le net j'ai trouvé ça :
http://dna.fernuni-hagen.de/secondo/...tion-Guide.txt
Et si je ne me trompe pas, cela vous permettra de créer les libraires concernées dans le bon format, qui pourront alors être exploitées avec votre api. Je ne penses pas que cela soit un problème de compilation...
personellement, je pense plutot qu'il y a eu une tentative de faire un System.load("letruc.jar") alors que l'appel devrait être System.load("letruc") ou System.load("letruc.so")
Je penses que l'on en saura plus avec le StackTrace... :D
Hello, I'm back !
Voila le stack trace :
D'après vos remarques, j'ai essayé System.load("jpl") et System.loadLibray("jpl"). Les deux appels se passent bien (enfin je suppose) pas de message d'erreur.Citation:
Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: no jpl in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1860)
at java.lang.Runtime.loadLibrary0(Runtime.java:845)
at java.lang.System.loadLibrary(System.java:1084)
at jpl.JPL.loadNativeLibrary(JPL.java:100)
at jpl.fli.Prolog.<clinit>(Prolog.java:85)
at jpl.Query.open(Query.java:286)
at jpl.Util.textToTerm(Util.java:162)
at jpl.Query.Query1(Query.java:183)
at jpl.Query.<init>(Query.java:176)
at use.prolog.prologFrame.jButton1MouseClicked(prologFrame.java:143)
at use.prolog.prologFrame.access$000(prologFrame.java:25)
at use.prolog.prologFrame$1.mouseClicked(prologFrame.java:98)
at java.awt.AWTEventMulticaster.mouseClicked(AWTEventMulticaster.java:270)
at java.awt.Component.processMouseEvent(Component.java:6508)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3321)
at java.awt.Component.processEvent(Component.java:6270)
at java.awt.Container.processEvent(Container.java:2229)
at java.awt.Component.dispatchEventImpl(Component.java:4861)
at java.awt.Container.dispatchEventImpl(Container.java:2287)
at java.awt.Component.dispatchEvent(Component.java:4687)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4501)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422)
at java.awt.Container.dispatchEventImpl(Container.java:2273)
at java.awt.Window.dispatchEventImpl(Window.java:2719)
at java.awt.Component.dispatchEvent(Component.java:4687)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:729)
at java.awt.EventQueue.access$200(EventQueue.java:103)
at java.awt.EventQueue$3.run(EventQueue.java:688)
at java.awt.EventQueue$3.run(EventQueue.java:686)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
at java.awt.EventQueue$4.run(EventQueue.java:702)
at java.awt.EventQueue$4.run(EventQueue.java:700)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:699)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
C'est lorsque j'ai vraiment besoin d'utiliser les fonctions du jpl que ça plante !
Bon, en tout cas, rien à voir avec les ELF dans ce message :)
que vaut java.library.path? Est-ce que ce path contient bien un dossier, contenant, lui, jpl.so ?
Pour référence futur, voilà le code de JPL.java
http://mirror.umd.edu/roswiki/doc/di...va_source.html
on voit à la ligne 100 qu'il ne fait rien de spécial pour le load, donc ce qui marche dans ton code (loadlibrary) devrais marcher dans la librairie.
Non, "d'origine" le java.library.path ne contient pas de répertoire contenant le jpl.so (au passage c'est un libjpl.so qui est créé, que j'ai recopié au même endroit en jpl.so).Citation:
Envoyé par tchize_
J'ai essayé de l'ajouter en bidouillant dans NetBeans mais je n'y arrive pas (je suis allé dans les propriétés du projet , et j'ai ajouté le répertoire contenant jpl.so dans les bibliothèques d'exécution).
Si je le fais à runtime (System.setProperty("java.library.path", "monrepertoire:".concat(System.gerProperty("java.library.path"))), ça ne fonctionne pas non plus.
dans netbeans, ce n'est pas dans les exécutables qu'il faut mettre ça, mais dans les options additionnelles de la jvm, il faut indiquer
-Djava.library.path=......
Je ne connais pas bien netbeans, mais dans eclipse il y a un onglet spécifique dans les paramètres d'exécution du projet pour y mettre ces paramètres supplémentaire, ça doit surement exister aussi dans netbeans :mrgreen:
et effectivement, le nom cherché par la jvm est libXXX.so où XXX est le nom passé au loadlibrary.
Bingo :lahola:
J'ai rajouté dans les options du projet, onglet Exécuter, options de la jvm -Djava.library.path=...... et ça fonctionne.
Merci !!!!
Bonjour,
Moi aussi j'ai le meme probleme et j'aimerais bien savoir plus de details sur comment tu as pu resoudre le probleme.
Pour information : Moi j'utilise un projet java sous unix qui fait appel a une methode native implementee en c++, donc j'appelle mon fichier .so et la mon message d'erreur ci-haut sort.
Merci.