Quote:
Enclenches tu une options particulière dans ton netbeans?
Rien en dehors que je que je t'ai dit à toi et aux autres. Simplement le -Djava.library.path=....
Quote:
As tu plus de détails sur les problmes que tu viens de me citer et des solutions possibles?
Bon je reprends une dernière fois pour essayer de clarifier au mieux.
De deux chose l'une.
Soit ça marche sous le shell et pas sous Netbeans. Soit ça ne marche pas du tout, ni sous shell ni sous Netbeans.
Si ça marche sous shell, alors tu te trompes en donnant le java.library.path sous Netbeans. Désolé de te ressortir ça, mais malheureusement il n'y a rien d'autre à dire. Le posteur intiial ayant dit que ça marchait sous shell avec lui, l'affaire était close de mon point de vue.
Si ça ne marche pas non plus sous shell (ce que dans ton cas tu ne précises pas), alors ta librairie native est mal construite. Dans ce cas deux possibilités:
- les fonctions de la librairie ne sont pas exportées, ce qui sous Linux paraît tout simplement impossible.
- Le compilateur C++ utilisé décore les noms de fonction. Décorer ça veut dire qu'en interne il ajoute des infos dans le nom de fonction pour des raisons trop longues à expliquer ici. Par exemple:
mafonction devient xxx25@_mafonction
Du coup la JVM qui essaie de charger mafonction ne la trouve pas dans la lib et lève l'exception qui te fait tant souffrir.
Dans ce cas il faut compiler avec une option qui, soit interdit au compilateur de décorer, soit définit un alias sans décoration dans la librairie. De mémoire avec g++ je dirais qu'il faut compiler avec
--add-stdcall-alias
Mais il faut vérifier en consultant la doc du compilateur bien sûr. D'ailleurs tu n'a pas dit lequel tu utilises.
Voilà tout ce que je peux te dire, et je t'assure qu'il n'y a rien d'autre à dire.
Rien en dehors que je que je t'ai dit à toi et aux autres. Simplement le -Djava.library.path=....
Bon je reprends une dernière fois pour essayer de clarifier au mieux.
De deux chose l'une.
Soit ça marche sous le shell et pas sous Netbeans. Soit ça ne marche pas du tout, ni sous shell ni sous Netbeans.
Si ça marche sous shell, alors tu te trompes en donnant le java.library.path sous Netbeans. Désolé de te ressortir ça, mais malheureusement il n'y a rien d'autre à dire. Le posteur intiial ayant dit que ça marchait sous shell avec lui, l'affaire était close de mon point de vue.
Si ça ne marche pas non plus sous shell (ce que dans ton cas tu ne précises pas), alors ta librairie native est mal construite. Dans ce cas deux possibilités:
- les fonctions de la librairie ne sont pas exportées, ce qui sous Linux paraît tout simplement impossible.
- Le compilateur C++ utilisé décore les noms de fonction. Décorer ça veut dire qu'en interne il ajoute des infos dans le nom de fonction pour des raisons trop longues à expliquer ici. Par exemple:
mafonction devient xxx25@_mafonction
Du coup la JVM qui essaie de charger mafonction ne la trouve pas dans la lib et lève l'exception qui te fait tant souffrir.
Dans ce cas il faut compiler avec une option qui, soit interdit au compilateur de décorer, soit définit un alias sans décoration dans la librairie. De mémoire avec g++ je dirais qu'il faut compiler avec
--add-stdcall-alias
Mais il faut vérifier en consultant la doc du compilateur bien sûr. D'ailleurs tu n'a pas dit lequel tu utilises.
Voilà tout ce que je peux te dire, et je t'assure qu'il n'y a rien d'autre à dire.