C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  [Solaris][g++] symbol _ZNSs20_S_empty_rep_storageE: referenc          C++Talk.NET Forum Index -> C++ (French) View previous topic :: View next topic   Author Message Guest Posted: Wed Aug 30, 2006 9:12 am    Post subject: [Solaris][g++] symbol _ZNSs20_S_empty_rep_storageE: referenc Bonjour, A l'aide de JNI, j'appelle depuis un .java un .cpp qui lui même appelle des librairies C++ fournies (dont je n'ai pas la source). Le lien Java -> C++ fonctionne. Lorsque j'intègre les méthodes issues des librairies cpp fournies, la compilation (à 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étaillé : [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ème peut-il venir d'une incompatibilité entre les compilations c++ (la mienne, avec gcc sous solaris, et celle des libs fournies avec cc sous linux) et comment les résoudre ? Merci par avance Back to top Fabien LE LEZ Guest Posted: Wed Aug 30, 2006 9:12 am    Post subject: Re: [Solaris][g++] symbol _ZNSs20_S_empty_rep_storageE: refe On 30 Aug 2006 01:58:42 -0700, florian.coroller (AT) gmail (DOT) com: Quote: java.lang.UnsatisfiedLinkError: no ISE in java.library.path Pour comprendre les codes d'erreur de Java, je te conseille plutôt fr.comp.lang.java. Back to top Rémy Guest Posted: Wed Aug 30, 2006 2:59 pm    Post subject: Re: [Solaris][g++] symbol _ZNSs20_S_empty_rep_storageE: refe <florian.coroller (AT) gmail (DOT) com> a écrit dans le message de news: 1156931229.327220.186920 (AT) p79g2000cwp (DOT) googlegroups.com... Quote: 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 Back to top kanze Guest Posted: Wed Aug 30, 2006 6:07 pm    Post subject: Re: [Solaris][g++] symbol _ZNSs20_S_empty_rep_storageE: refe florian.coroller (AT) gmail (DOT) com wrote: Quote: 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 Back to top kanze Guest Posted: Wed Aug 30, 2006 6:13 pm    Post subject: Re: [Solaris][g++] symbol _ZNSs20_S_empty_rep_storageE: refe Rémy wrote: Quote: florian.coroller (AT) gmail (DOT) com> a écrit dans le message de news: 1156931229.327220.186920 (AT) p79g2000cwp (DOT) 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++.) Quote: - 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. Quote: - 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 Back to top Alain Gaillard Guest Posted: Wed Aug 30, 2006 6:16 pm    Post subject: Re: [Solaris][g++] symbol _ZNSs20_S_empty_rep_storageE: refe kanze a écrit : Quote: 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: java -Djava.library.path=/le_repertoire_qui_contient_ma_lib MaClasse Etant évidemment entendu qui faut recompiler la lib pour Windows :) -- Alain Back to top kanze Guest Posted: Wed Aug 30, 2006 6:23 pm    Post subject: Re: [Solaris][g++] symbol _ZNSs20_S_empty_rep_storageE: refe Alain Gaillard wrote: Quote: florian.coroller (AT) gmail (DOT) com a écrit : 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++.) Quote: 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 -Djava.library.path=/le_repertoire qui_contient_le_so MaClasse 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. Quote: 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 Back to top Alain Gaillard Guest Posted: Wed Aug 30, 2006 8:42 pm    Post subject: Re: [Solaris][g++] symbol _ZNSs20_S_empty_rep_storageE: refe kanze a écrit : Quote: java -Djava.library.path=/le_repertoire qui_contient_le_so MaClasse 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 Back to top SamR Guest Posted: Thu Aug 31, 2006 9:11 am    Post subject: Re: [Solaris][g++] symbol _ZNSs20_S_empty_rep_storageE: refe 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.. 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. Back to top kanze Guest Posted: Thu Aug 31, 2006 9:11 am    Post subject: Re: [Solaris][g++] symbol _ZNSs20_S_empty_rep_storageE: refe Alain Gaillard wrote: Quote: kanze a écrit : java -Djava.library.path=/le_repertoire qui_contient_le_so MaClasse 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. Il me semble avoir vu une variable statique dans l'implémentation de std::string chez g++ (mais dans quelle version -- je ne m'en souviens plus) qui avail le même nom, ou un nom semblable, à celui qui lui manque. Du coup, je soupçonne quelque chose qui sert dans son propre code : soit qu'il ne trouve pas libstdc++, soit que la version installée n'est pas compatible avec la version dont il s'est servi pour générer son code. Quote: Enfin bref, si la ou les librairies sont pointées correctement, sous Linux c'est impossible que ça ne marche pas. Je vois que tu n'as pas beaucoup d'expérience dans le domaine. Si la bibliothèque n'est pas installée sur la machine (souvent le cas de libstdc++.so), tu ne peux pas le rétrouver, quoique tu mets dans LD_LIBRARY_PATH. Et si la version installée n'est pas compatible avec la version dont tu t'es servi lors de la génération de ton programme, ça risque de poser des problèmes aussi. C'est pourquoi je lie toujours libstdc++ en statique. Quote: 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.... À moi aussi. Mais s'il est rélativement débuttant, et que sa seule expérience jusqu'ici est en Java (ou Basic, ou d'autres langages qui sont plus ou moins interprétés). Quote: 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. Il reste que s'il compile avec g++ 4.1.0, et le g++ installait sur la machine où exécute le programme est g++ 2.95.2, ça ne va certainement pas marcher sans l'option -static-libgcc. Et que pour le connaître, il faut bien avoir lu le manual g++. Je viens de vérifier sur mes copies des sources de g++. Le symbole dont il a besoin est bien référencé dans basic_string.tcc ; il est donc démandé si son code C++ utilise std::string. Et il est défini dans un fichier string-inst.o, qui fait bien partie de libstdc++ -- dans libstdc++.so.6.0.7 du g++ 4.1.0. Dans libstdc++.so.6.0.3, du g++ 3.4.3, le nom est légèrement différent. Donc, s'il développe avec g++ 4.1.0, mais que le g++ installé où le programme tourne est g++ 3.4.3, il aurait exactement l'erreur qu'il décrit. Dans les faits : à l'encontre de la bibliothèque C, il n'y a pas de API « standard » pour la bibliothèque C++. Chaque implémenteur en fait ce qu'il veut, et c'est plutôt courant que ça change d'une version à l'autre. (G++ n'est pas le seul à se comporter comme ça.) En plus, la bibliothèque C++ n'est typiquement présente que si le compilateur g++ a été installé sur le système -- si c'est souvent le cas avec Linux, c'est bien moins fréquent sous Unix. Du coup, au moins de vouloir vraiment des emmerdes, on doit 1) lier libstdc++ en statique, au moyen de l'option -static-libgcc, 2) ne pas utiliser quoique ce soit de la bibliothèque C++ à l'interface entre les .so, et 3) ne pas laisser des exceptions traverser l'interface des .so. En ce qui concerne les JNI, les deux dernières conditions sont remplies d'office. Qu'il ajoute -static-libgcc à la ligne de commande qui génère le .so, et tout doit rentrer dans l'ordre. (À condition que tout marche comme ça doit marcher ; il me semble avoir vu un rapport de bug sur -static-libgcc, qu'il ne marche pas toujours comme il faut.) -- 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 Back to top Alain Gaillard Guest Posted: Thu Aug 31, 2006 9:11 am    Post subject: Re: [Solaris][g++] symbol _ZNSs20_S_empty_rep_storageE: refe SamR a écrit : Quote: 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). Dis donc, ce que tu nous dis là ne reflète pas ta question initiale je trouve... :-S Quote: fournis). Au moment de la compilation, il ne trouve pas les librairies math_iso.h (ainsi que d'autres librairies). Mais alors si tu en es là seulement, comment tu peux nous dire que le JVM te lève exception UnsatisfiedKinnError ? Bref, peu importe. Maintenant à relire ton post initial, on dirait que tu te heurtes à un problème de décoration de noms de fonctions. Normalement quand tu compiles pour JNI tu n'as pas ce problème cat dans jni.h il y a #ifdef __cplusplus extern "C" { #endif qui t'arrange le coup automatiquement, au moins sur g++. C'est pour ça que je disais qu'il n'y a même pas besoin de lire la doc. Mais si tu utilise d'autres librairies en plus que celle que tu as écrites, alors peut être que quand tu compiles un nom de fonction est décoré "à la C++". Vois s'il n'y manque pas un extern "C" quelque part, dans la zone d'un "empty_rep_storage" comme ton post initial le suggère. Quote: 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 Si tu as tous les sources pourquoi pas ? Mais ça risque de te demander du travail. Quote: Merci encore pour votre aide. De rien, en espérant t'avoir mieux aidé cette fois. -- Alain Back to top kanze Guest Posted: Thu Aug 31, 2006 2:50 pm    Post subject: Re: [Solaris][g++] symbol _ZNSs20_S_empty_rep_storageE: refe SamR wrote: Quote: 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). LD_LIBRARY_PATH n'a rien à voir avec Java. N'oublie pas que la JVM qui exécute ton Java est écrit, lui aussi, en C ou en C++. Et qu'elle utilise, à la base, les mêmes bibliothèques système que ton C++ (en l'occurance, les fonctions dlopen/dlsym). Quote: 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. Avec quelle version de g++ ? Quote: J'essaye pour le moment de les recompiler sous Solaris (Sparc2.. 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. En format source, ou comme .so. Si le code est en C++, et que les bibliothèques ont été compilées avec Sun CC, elles ne marcheront pas avec du code compilé avec g++. Quote: 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++. Quel environnement ? Je développe à 90% sous Solaris, et avec Sun CC et avec g++, et je n'ai pas de problème. Le fichier math_iso.h se trouve dans /usr/include/iso ; il fait parti du package SUNWlibm, qui doit être installé d'office (je crois). Ensuite, si g++ est installé correctement, il doit le trouver. (Il le trouve chez moi.) Essaie g++ -v sur une source triviale, et régarder le chemin qu'il cherche : /usr/include doit être à la fin (et l'include doit être de <iso/math_iso.h> dans le math.h qu'il trouve). Sinon, c'est un problème d'installation de g++, et il faudrait démander dans les groupes spécialisées gcc. Quote: 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 crois, si tu as des .a, et non seulement des .so. Je ne l'ai pas essayé, mais je crois que si tu précises -B static avant le -l option, l'éditeur de liens prends la version .a de préférence, et l'incorpore statiquement. Si tu invoques l'éditeur de liens à travers g++ (fortement conseillé), il faut bien lui dire de passer et le -B et le static à l'éditeur de liens, donc : g++ ... -Xlinker -B -Xlinker static -lcrypto \ -Xlinker -B -Xlinker static -lSSl ... (Je ne suis pas trop sûr si ça marche pour la génération des objets dynamiques, mais on s'en sert extensivement ici pour les binaires. Aussi, un essaie rapide me donne l'impression que -static-libgcc ne fonctionne pas, au moins sur Solaris.) -- 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 Back to top Alain Gaillard Guest Posted: Thu Aug 31, 2006 2:52 pm    Post subject: Re: [Solaris][g++] symbol _ZNSs20_S_empty_rep_storageE: refe kanze a écrit : Quote: Il me semble avoir vu une variable statique dans l'implémentation de std::string chez g++ (mais dans quelle version -- je ne m'en souviens plus) qui avail le même nom, ou un nom semblable, à celui qui lui manque. Du coup, je soupçonne quelque chose qui sert dans son propre code : soit qu'il ne trouve pas libstdc++, soit que la version installée n'est pas compatible avec la version dont il s'est servi pour générer son code. Ah oui ça pourrait expliquer bien des choses. Quote: Enfin bref, si la ou les librairies sont pointées correctement, sous Linux c'est impossible que ça ne marche pas. Je vois que tu n'as pas beaucoup d'expérience dans le domaine. Si la bibliothèque n'est pas installée sur la machine Ah ce bon vieux James. Toujours aussi taquin et plein d'humour. Allons allons... J'ai écrit "si la ou les librairies sont pointées correctement" Pour qu'elles soient pointées faut aussi qu'elles soit présentes. Ca tombe quand même sous le sens. Quote: (souvent le cas de libstdc++.so), tu ne peux pas le rétrouver, Si tu l'as paumée c'est ton problème :-) Quote: quoique tu mets dans LD_LIBRARY_PATH. N'importe quoi.... Si LD_LIBRARY_PATH pointe dessus tu la trouves. En admettant même qu'il faille toucher à cette variable d'environnement. Sur une distribution Linux "d'origine' si je peux dire, libstdc++.so est toujours pointée depuis le ld.so.conf. Enfin je n'ai jamais vu autre chose. Il y a tellement de distrib tu me diras... Evidemment si un autre g++ a été installé à posteriori ou si plusieurs versions cohabitent c'est autre chose. Mais si quelqu'un sait faire ça, ça m'étonnerait qu'il fasse une édition de liens incorrecte. Quote: Et si la version installée n'est pas compatible avec la version dont tu t'es servi lors de la génération de ton programme, ça risque de poser des problèmes aussi. Ah ça oui, c'est bien possible. Quote: C'est pourquoi je lie toujours libstdc++ en statique. Oui je suis d'accord, c'est une sage précaution. Quote: Je viens de vérifier sur mes copies des sources de g++. Le symbole dont il a besoin est bien référencé dans basic_string.tcc ; il est donc démandé si son code C++ utilise std::string. Et il est défini dans un fichier string-inst.o, qui fait bien partie de libstdc++ -- dans libstdc++.so.6.0.7 du g++ 4.1.0. Dans libstdc++.so.6.0.3, du g++ 3.4.3, le nom est légèrement différent. Donc, s'il développe avec g++ 4.1.0, mais que le g++ installé où le programme tourne est g++ 3.4.3, il aurait exactement l'erreur qu'il décrit. Oui ça explique bien des choses. En fait comme il disait que la librairie native ne chargeait pas sous JVM, je suis parti du principe quelle fonctionnait correctement par elle même. Si la librairie n'a pas été construite correctement, c'est une autre affaire. D'ailleurs à lire le post de ce matin du posteur initial, c'est bien là que se situe la difficulté. -- Alain Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ (French) All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.