[Solaris][g++] symbol _ZNSs20_S_empty_rep_storageE: referenced symbol not found
14 réponses
florian.coroller
Bonjour,
A l'aide de JNI, j'appelle depuis un .java un .cpp qui lui m=EAme
appelle des librairies C++ fournies (dont je n'ai pas la source). Le
lien Java -> C++ fonctionne.
Lorsque j'int=E8gre les m=E9thodes issues des librairies cpp fournies, la
compilation (=E0 l'aide de g++) fonctionne, mais au moment de
l'execution du .class, j'ai l'erreur suivante :
java.lang.UnsatisfiedLinkError: no ISE in java.library.path
Je ne pense pas qu'il s'agisse d'une erreur de classpath. En rajoutant
l'option verbose :
java -verbose:jni ISE, j'obtiens un message plus d=E9taill=E9 :
[Unable to load native library: /space2/data/tmp/fcor/ise/libISE.so]
ld.so.1:
/usr/bin/../java/bin/../jre/bin/../bin/sparc/native_threads/java:
fatal: relocation error: file /space2/data/tmp/fcor/ise/libISE.so:
symbol _ZNSs20_S_empty_rep_storageE: referenced symbol not found
Il semblerait que _ZNSs20_S_empty_rep_storageE est inclue dans les
librairies du compilateur ?
Le probl=E8me peut-il venir d'une incompatibilit=E9 entre les
compilations c++ (la mienne, avec gcc sous solaris, et celle des libs
fournies avec cc sous linux) et comment les r=E9soudre ?
Pour comprendre les codes d'erreur de Java, je te conseille plutôt fr.comp.lang.java.
Certes, mais l'erreur Java est générée par une erreur C++... D'où ma question sur ce groupe.
Et c'est cette erreur C++ qui m'interesse :
symbol _ZNSs20_S_empty_rep_storageE: referenced symbol not found
Merci quand même.
Rémy
a écrit dans le message de news:
Et c'est cette erreur C++ qui m'interesse :
symbol _ZNSs20_S_empty_rep_storageE: referenced symbol not found
Merci quand même.
Il semble que la librairie /space2/data/tmp/fcor/ise/libISE.so aie besoin de ce symbole (qui doit être défini dans une autre librairie).
- Soit ce symbole n'y a pas le même nom (pour cause de compilateur différent par exemple), mais si vous avez vous même généré cette librairie, c'est peu probable. - Soit cette autre librairie n'est pas trouvée (à ce sujet, j'ai été obligé de renseigner la variable LD_LIBRARY_PATH avant de lancer Java pour que les dépendances entre les librairies soient correctement traitées).
Rémy
<florian.coroller@gmail.com> a écrit dans le message de news:
1156931229.327220.186920@p79g2000cwp.googlegroups.com...
Et c'est cette erreur C++ qui m'interesse :
symbol _ZNSs20_S_empty_rep_storageE: referenced symbol not found
Merci quand même.
Il semble que la librairie /space2/data/tmp/fcor/ise/libISE.so aie besoin de
ce symbole (qui doit être défini dans une autre librairie).
- Soit ce symbole n'y a pas le même nom (pour cause de compilateur différent
par exemple), mais si vous avez vous même généré cette librairie, c'est peu
probable.
- Soit cette autre librairie n'est pas trouvée (à ce sujet, j'ai été obligé
de renseigner la variable LD_LIBRARY_PATH avant de lancer Java pour que les
dépendances entre les librairies soient correctement traitées).
symbol _ZNSs20_S_empty_rep_storageE: referenced symbol not found
Merci quand même.
Il semble que la librairie /space2/data/tmp/fcor/ise/libISE.so aie besoin de ce symbole (qui doit être défini dans une autre librairie).
- Soit ce symbole n'y a pas le même nom (pour cause de compilateur différent par exemple), mais si vous avez vous même généré cette librairie, c'est peu probable. - Soit cette autre librairie n'est pas trouvée (à ce sujet, j'ai été obligé de renseigner la variable LD_LIBRARY_PATH avant de lancer Java pour que les dépendances entre les librairies soient correctement traitées).
Rémy
kanze
wrote:
Pour comprendre les codes d'erreur de Java, je te conseille plutôt fr.comp.lang.java.
Certes, mais l'erreur Java est générée par une erreur C++... D'où ma question sur ce groupe.
Et c'est cette erreur C++ qui m'interesse :
symbol _ZNSs20_S_empty_rep_storageE: referenced symbol not found
Sauf que c'est bien une erreur du chargeur de Java, et non du C++.
En fait (mais je sais celà seulement parce que je connais le Java, le JNI et l'implémentation particulière du C++ dont tu te sers), il s'agit d'un problème de link dynamique. Normalement, je dirais soit d'ajouter l'option -static-libgcc à la ligne de commande lorsque tu génères la bibliothèque, soit de s'assurer que la version dynamique de la bibliothèque libstdc++.so se trouve sur le système où tourne l'application, et qu'elle soit dans le chemin prévu pour le trouver ($LD_LIBRARY_PATH).
Je dis normalement, parce que tu as dis une chose un peu étonnant : que tu as compilé sous Solaris (sur un Sparc), et que tu exécutes sous Linux (sur un PC ?). Et ça, ça ne peut jamais fonctionner -- les instructions machines pour les deux machines sont complètement différentes. (Si ça fonctionne avec Java, c'est parce que Java est soit interprété soit récompilé et rélinké à chaque exécution.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
florian.coroller@gmail.com wrote:
Pour comprendre les codes d'erreur de Java, je te conseille
plutôt fr.comp.lang.java.
Certes, mais l'erreur Java est générée par une erreur C++...
D'où ma question sur ce groupe.
Et c'est cette erreur C++ qui m'interesse :
symbol _ZNSs20_S_empty_rep_storageE: referenced symbol not found
Sauf que c'est bien une erreur du chargeur de Java, et non du
C++.
En fait (mais je sais celà seulement parce que je connais le
Java, le JNI et l'implémentation particulière du C++ dont tu te
sers), il s'agit d'un problème de link dynamique. Normalement,
je dirais soit d'ajouter l'option -static-libgcc à la ligne de
commande lorsque tu génères la bibliothèque, soit de s'assurer
que la version dynamique de la bibliothèque libstdc++.so se
trouve sur le système où tourne l'application, et qu'elle soit
dans le chemin prévu pour le trouver ($LD_LIBRARY_PATH).
Je dis normalement, parce que tu as dis une chose un peu
étonnant : que tu as compilé sous Solaris (sur un Sparc), et
que tu exécutes sous Linux (sur un PC ?). Et ça, ça ne peut
jamais fonctionner -- les instructions machines pour les deux
machines sont complètement différentes. (Si ça fonctionne avec
Java, c'est parce que Java est soit interprété soit récompilé et
rélinké à chaque exécution.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Pour comprendre les codes d'erreur de Java, je te conseille plutôt fr.comp.lang.java.
Certes, mais l'erreur Java est générée par une erreur C++... D'où ma question sur ce groupe.
Et c'est cette erreur C++ qui m'interesse :
symbol _ZNSs20_S_empty_rep_storageE: referenced symbol not found
Sauf que c'est bien une erreur du chargeur de Java, et non du C++.
En fait (mais je sais celà seulement parce que je connais le Java, le JNI et l'implémentation particulière du C++ dont tu te sers), il s'agit d'un problème de link dynamique. Normalement, je dirais soit d'ajouter l'option -static-libgcc à la ligne de commande lorsque tu génères la bibliothèque, soit de s'assurer que la version dynamique de la bibliothèque libstdc++.so se trouve sur le système où tourne l'application, et qu'elle soit dans le chemin prévu pour le trouver ($LD_LIBRARY_PATH).
Je dis normalement, parce que tu as dis une chose un peu étonnant : que tu as compilé sous Solaris (sur un Sparc), et que tu exécutes sous Linux (sur un PC ?). Et ça, ça ne peut jamais fonctionner -- les instructions machines pour les deux machines sont complètement différentes. (Si ça fonctionne avec Java, c'est parce que Java est soit interprété soit récompilé et rélinké à chaque exécution.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Rémy wrote:
a écrit dans le message de news:
Et c'est cette erreur C++ qui m'interesse :
symbol _ZNSs20_S_empty_rep_storageE: referenced symbol not found
Il semble que la librairie /space2/data/tmp/fcor/ise/libISE.so aie besoin de ce symbole (qui doit être défini dans une autre librairie).
À vue d'oeil, je crois que ce symbole fait partie de l'implémentation du std::string du g++. C-à-d qu'il se trouve dans libstdc++.so. (Mais peut-être je le confonds avec un autre symbole. Ou une version plus ancienne de g++.)
- Soit ce symbole n'y a pas le même nom (pour cause de compilateur différent par exemple), mais si vous avez vous même généré cette librairie, c'est peu probable.
Attention : il a dit qu'il compile sous Solaris, et exécute le Java sous Linux.
- Soit cette autre librairie n'est pas trouvée (à ce sujet, j'ai été obligé de renseigner la variable LD_LIBRARY_PATH avant de lancer Java pour que les dépendances entre les librairies soient correctement traitées).
Et pour le renseigner, il faut savoir où se trouve la bibliothèque en question:-). À condition, évidemment, qu'elle soit présente. Dans la bonne versions. (C'est un des problèmes avec les éditions de liens dynamiques.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Rémy wrote:
<florian.coroller@gmail.com> a écrit dans le message de news:
1156931229.327220.186920@p79g2000cwp.googlegroups.com...
Et c'est cette erreur C++ qui m'interesse :
symbol _ZNSs20_S_empty_rep_storageE: referenced symbol not found
Il semble que la librairie /space2/data/tmp/fcor/ise/libISE.so
aie besoin de ce symbole (qui doit être défini dans une autre
librairie).
À vue d'oeil, je crois que ce symbole fait partie de
l'implémentation du std::string du g++. C-à-d qu'il se trouve
dans libstdc++.so. (Mais peut-être je le confonds avec un autre
symbole. Ou une version plus ancienne de g++.)
- Soit ce symbole n'y a pas le même nom (pour cause de
compilateur différent par exemple), mais si vous avez vous
même généré cette librairie, c'est peu probable.
Attention : il a dit qu'il compile sous Solaris, et exécute le
Java sous Linux.
- Soit cette autre librairie n'est pas trouvée (à ce sujet,
j'ai été obligé de renseigner la variable LD_LIBRARY_PATH
avant de lancer Java pour que les dépendances entre les
librairies soient correctement traitées).
Et pour le renseigner, il faut savoir où se trouve la
bibliothèque en question:-). À condition, évidemment, qu'elle
soit présente. Dans la bonne versions. (C'est un des problèmes
avec les éditions de liens dynamiques.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
symbol _ZNSs20_S_empty_rep_storageE: referenced symbol not found
Il semble que la librairie /space2/data/tmp/fcor/ise/libISE.so aie besoin de ce symbole (qui doit être défini dans une autre librairie).
À vue d'oeil, je crois que ce symbole fait partie de l'implémentation du std::string du g++. C-à-d qu'il se trouve dans libstdc++.so. (Mais peut-être je le confonds avec un autre symbole. Ou une version plus ancienne de g++.)
- Soit ce symbole n'y a pas le même nom (pour cause de compilateur différent par exemple), mais si vous avez vous même généré cette librairie, c'est peu probable.
Attention : il a dit qu'il compile sous Solaris, et exécute le Java sous Linux.
- Soit cette autre librairie n'est pas trouvée (à ce sujet, j'ai été obligé de renseigner la variable LD_LIBRARY_PATH avant de lancer Java pour que les dépendances entre les librairies soient correctement traitées).
Et pour le renseigner, il faut savoir où se trouve la bibliothèque en question:-). À condition, évidemment, qu'elle soit présente. Dans la bonne versions. (C'est un des problèmes avec les éditions de liens dynamiques.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Alain Gaillard
dans le chemin prévu pour le trouver ($LD_LIBRARY_PATH).
Mais comme Java a la prétention de tourner sous Windows, le mieux est de donner partout la commande:
Etant évidemment entendu qui faut recompiler la lib pour Windows :)
-- Alain
kanze
Alain Gaillard wrote:
java.lang.UnsatisfiedLinkError: no ISE in java.library.path
Ton problème n'est pas du côté C++. C'est une question typique Java donc hors sujet ici normalement... ->
Son problème est ni du côté Java, ni du côté C++. C'est un problème d'environnement (Linux), avec des solutions possibles qui dépendent du compilateur (g++).
Pour le résoudre, il faut connaître non seulement le Java, mais aussi Linux, et il faut avoir lu le manuel de g++. (En fait, à peu près la seule chose qu'on n'a pas besoin de connaître pour le résoudre, c'est le C++.)
Je ne pense pas qu'il s'agisse d'une erreur de classpath. En rajoutant
... -> Mais comme avec Java on rencontre toujours des **** de ce genre, je vais t'aider, parce que je sais trop à quel point c'est énervant.
Sauf que si j'ai bien compris, il trouve sa propre classe. Ce sont les bibliothèques utilisées par ses classes qui posent le problème.
Pour des explications détaillées, le mieux est que tu te tournes vers un groupe dédié à Java.
Plutôt Linux ou g++, je crois.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Alain Gaillard wrote:
java.lang.UnsatisfiedLinkError: no ISE in java.library.path
Ton problème n'est pas du côté C++.
C'est une question typique Java donc hors sujet ici normalement... ->
Son problème est ni du côté Java, ni du côté C++. C'est un
problème d'environnement (Linux), avec des solutions possibles
qui dépendent du compilateur (g++).
Pour le résoudre, il faut connaître non seulement le Java, mais
aussi Linux, et il faut avoir lu le manuel de g++. (En fait, à
peu près la seule chose qu'on n'a pas besoin de connaître pour
le résoudre, c'est le C++.)
Je ne pense pas qu'il s'agisse d'une erreur de classpath. En rajoutant
... -> Mais comme avec Java on rencontre toujours des **** de ce genre,
je vais t'aider, parce que je sais trop à quel point c'est énervant.
java.lang.UnsatisfiedLinkError: no ISE in java.library.path
Ton problème n'est pas du côté C++. C'est une question typique Java donc hors sujet ici normalement... ->
Son problème est ni du côté Java, ni du côté C++. C'est un problème d'environnement (Linux), avec des solutions possibles qui dépendent du compilateur (g++).
Pour le résoudre, il faut connaître non seulement le Java, mais aussi Linux, et il faut avoir lu le manuel de g++. (En fait, à peu près la seule chose qu'on n'a pas besoin de connaître pour le résoudre, c'est le C++.)
Je ne pense pas qu'il s'agisse d'une erreur de classpath. En rajoutant
... -> Mais comme avec Java on rencontre toujours des **** de ce genre, je vais t'aider, parce que je sais trop à quel point c'est énervant.
Sauf que si j'ai bien compris, il trouve sa propre classe. Ce sont les bibliothèques utilisées par ses classes qui posent le problème.
Il n'est pas question ici de trouver sa propre classe, mais bien les bibliothèques native utilisées pas ses classes Java. A moins que tu ais voulu dire sa propre librairie native. De toutes façons, normalement un -Djava.library.path (ou un LD_LIBRARY_PATH) correctement positionné règle ce problème.
Enfin bref, si la ou les librairies sont pointées correctement, sous Linux c'est impossible que ça ne marche pas. Ou alors comme tu l'as dit dans un autre post, c'est qu'il utilise sous Linux une librairie compilée pour Solaris. Mais ça paraît tellement incroyable....
Dans ce cas la solution c'est évidemment de compiler sous Linux.... et ce n'est même pas la peine de regarder la doc de g++. Spécialement pour ça je veut dire.
Sauf que si j'ai bien compris, il trouve sa propre classe. Ce
sont les bibliothèques utilisées par ses classes qui posent le
problème.
Il n'est pas question ici de trouver sa propre classe, mais bien les
bibliothèques native utilisées pas ses classes Java. A moins que tu ais
voulu dire sa propre librairie native. De toutes façons, normalement un
-Djava.library.path (ou un LD_LIBRARY_PATH) correctement positionné
règle ce problème.
Enfin bref, si la ou les librairies sont pointées correctement, sous
Linux c'est impossible que ça ne marche pas. Ou alors comme tu l'as dit
dans un autre post, c'est qu'il utilise sous Linux une librairie
compilée pour Solaris. Mais ça paraît tellement incroyable....
Dans ce cas la solution c'est évidemment de compiler sous Linux.... et
ce n'est même pas la peine de regarder la doc de g++. Spécialement pour
ça je veut dire.
Sauf que si j'ai bien compris, il trouve sa propre classe. Ce sont les bibliothèques utilisées par ses classes qui posent le problème.
Il n'est pas question ici de trouver sa propre classe, mais bien les bibliothèques native utilisées pas ses classes Java. A moins que tu ais voulu dire sa propre librairie native. De toutes façons, normalement un -Djava.library.path (ou un LD_LIBRARY_PATH) correctement positionné règle ce problème.
Enfin bref, si la ou les librairies sont pointées correctement, sous Linux c'est impossible que ça ne marche pas. Ou alors comme tu l'as dit dans un autre post, c'est qu'il utilise sous Linux une librairie compilée pour Solaris. Mais ça paraît tellement incroyable....
Dans ce cas la solution c'est évidemment de compiler sous Linux.... et ce n'est même pas la peine de regarder la doc de g++. Spécialement pour ça je veut dire.
-- Alain
SamR
Bonjour,
Pour commencer, merci à tous pour vos réponses.
Je continue d'avancer dans l'investigation de ce problème.
kanze est certainement la personne la plus proche. Modifier ou positionner le LD_LIBRARY_PATH ne sert à rien (pour le moment en tout cas), pour la simple est bonne raison que si j'essaye de faire un executable C++ ça ne fonctionne pas non plus (donc rien à voir avec le Java).
Je résume la situation :
Java ---JNI----> C++ (solaris) -----> C++ (linux)
Les librairies C++ fournies par mon client ont visiblement été compilées sous Linux. J'essaye pour le moment de les recompiler sous Solaris (Sparc2.8). Or ces librairies utilisent le package OpenSSL et notamment les libraires libcrypto.so et libSSL.so. J'ai donc téléchargé ce package pour permettre l'éxecution. J'ai tenté de le compiler en modifiant le makefile pour Solaris (à l'aide des scripts fournis). Au moment de la compilation, il ne trouve pas les librairies math_iso.h (ainsi que d'autres librairies). Je découvre en fait que mon environnement n'est pas vraiment viable pour le développement C++.
Je vais donc tant bien que mal essayer de trouver toutes les dépendances et recompiler tout ce bazar.
J'ai cependant une question, est-il possible de compiler un fichier .cpp pour en faire une dll qui intégrerait en elle toutes les dépendances possibles afin d'obtenir une unique librairie (et ce afin de faciliter le déploiement sur d'autres environnement (qualif, prod)).
Merci encore pour votre aide.
Bonjour,
Pour commencer, merci à tous pour vos réponses.
Je continue d'avancer dans l'investigation de ce problème.
kanze est certainement la personne la plus proche.
Modifier ou positionner le LD_LIBRARY_PATH ne sert à rien (pour le
moment en tout cas), pour la simple est bonne raison que si j'essaye de
faire un executable C++ ça ne fonctionne pas non plus (donc rien à
voir avec le Java).
Je résume la situation :
Java ---JNI----> C++ (solaris) -----> C++ (linux)
Les librairies C++ fournies par mon client ont visiblement été
compilées sous Linux. J'essaye pour le moment de les recompiler sous
Solaris (Sparc2.8). Or ces librairies utilisent le package OpenSSL et
notamment les libraires libcrypto.so et libSSL.so. J'ai donc
téléchargé ce package pour permettre l'éxecution. J'ai tenté de le
compiler en modifiant le makefile pour Solaris (à l'aide des scripts
fournis). Au moment de la compilation, il ne trouve pas les librairies
math_iso.h (ainsi que d'autres librairies).
Je découvre en fait que mon environnement n'est pas vraiment viable
pour le développement C++.
Je vais donc tant bien que mal essayer de trouver toutes les
dépendances et recompiler tout ce bazar.
J'ai cependant une question, est-il possible de compiler un fichier
.cpp pour en faire une dll qui intégrerait en elle toutes les
dépendances possibles afin d'obtenir une unique librairie (et ce afin
de faciliter le déploiement sur d'autres environnement (qualif,
prod)).
Je continue d'avancer dans l'investigation de ce problème.
kanze est certainement la personne la plus proche. Modifier ou positionner le LD_LIBRARY_PATH ne sert à rien (pour le moment en tout cas), pour la simple est bonne raison que si j'essaye de faire un executable C++ ça ne fonctionne pas non plus (donc rien à voir avec le Java).
Je résume la situation :
Java ---JNI----> C++ (solaris) -----> C++ (linux)
Les librairies C++ fournies par mon client ont visiblement été compilées sous Linux. J'essaye pour le moment de les recompiler sous Solaris (Sparc2.8). Or ces librairies utilisent le package OpenSSL et notamment les libraires libcrypto.so et libSSL.so. J'ai donc téléchargé ce package pour permettre l'éxecution. J'ai tenté de le compiler en modifiant le makefile pour Solaris (à l'aide des scripts fournis). Au moment de la compilation, il ne trouve pas les librairies math_iso.h (ainsi que d'autres librairies). Je découvre en fait que mon environnement n'est pas vraiment viable pour le développement C++.
Je vais donc tant bien que mal essayer de trouver toutes les dépendances et recompiler tout ce bazar.
J'ai cependant une question, est-il possible de compiler un fichier .cpp pour en faire une dll qui intégrerait en elle toutes les dépendances possibles afin d'obtenir une unique librairie (et ce afin de faciliter le déploiement sur d'autres environnement (qualif, prod)).
