crebondiou pourquoi ça marche pas!
 
je galère sur un probleme de résolution des symboles. Je ne sais absolument pas à quoi cela correspond!
je vous explique (du moins j'essaie). J'ai un programme qui lance un plugin.  
tout d'abord je charge le plugin et apres je le lance. Mais lors du chargement, le dlopen echoue.  
J'aimerai bien savoir pourquoi!
 
Précision.  
dans une premièere version ce plugin incluait des fichiers c++. La j'ai inclu des fichiers utilisant QT, j'ai mis les lib qui vont bien dans le makefile du repertoire de plugin mais voilà rien à faire je ne comprend pas!
 
 
Voici l'erreur envoyée par la console à l'execution (a la compil, no soucaï):
Trouvé : Plugins/ES_VRML.plg
erreur (renvoyé pas dlerror)Plugins/ES_VRML.plg: undefined symbol: _ZNK16EnsembleDePoints12nombrePointsEv
Bibliothèque non trouvée
(ça ne plante pas mais comme ma bibliothèque n'est pas trouvée, je ne peux rien faire)
 
Merci de m'éclairer de vos lumières!

Quel OS ?
Et ça donne quoi si tu fais un ldd sur ton plugin (je suppose que c'est une shared lib), et un ldd sur l'exécutable hôte ?

je travaille sous linux.  
je viens d'essayer ldd et je ne comprend rien...effectivement il y a une liste impressionnante de librairies mais à quoi ça sert?
ce ne sont que des librairies bas niveau
 
<console>
ldd  Plugins/ES_VRML.plg
                libdl.so.2 => /lib/tls/libdl.so.2 (0x40029000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4002d000)
        libm.so.6 => /lib/tls/libm.so.6 (0x400e7000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4010a000)
        libc.so.6 => /lib/tls/libc.so.6 (0x40113000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
<\console>
 
je fais quoi avec tout ca?

sur l'éxécutable c'est trop long pour le mettre ici mais si tu insistes...
no pb

Euh nan, donne moi juste le résultat de  
ldd ton-executable | grep libstdc

libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x408e3000)

Mais EnsembleDePoints, ça sort d'où ?  
 
Parce qu'à priori, je comprendrais que ça merdoie pour un dlsym, mais si dès le dlopen ça foire, c'est que quelque part, le post-linker (libdl en fait) s'attend à le trouver, mais ne le voit pas. Es-tu sûre de l'inclure dans ton plug-in ?  

EnsembleDePoints est inclu dans ES_VRML, il faisait partie de la première version qui marchait nickel:
<CODE>
#include <cstdlib>
#include <iostream>
 
#include <vector>
#include <string>
#include <fstream>
 
#include "forme.h"                 //
#include "constantes.h"            //
#include "polyligne.h"             //2ème version(la buggée)
#include "cercle.h"                //
#include "courbeBezier.h"          //
#include "courbeCardinalSpline.h"  //
#include "face.h"              /
#include "point3d.h"           / 1ère version qui marchait
#include "ensembleDePoints.h"  /
#include "ensembleDeFaces.h"   /
 
<\CODE>
 
j'ai revérifié le makefile du plugin et de l'executable, ensembleDePoints.h est bien inclu.
A part ça, pourquoi le dlsym devrait merdouiller?

Euh, le code se trouve seulement dans le .h ? Il n'y a pas de ensembleDePoints.cpp ou autres ?
 
Sinon, il n'y a pas de raisons que dlsym rate, mais si ça rate, c'est généralement l'endroit où on s'attend à trouver un problème de symbole non trouvé, et non pas au niveau du dlopen.

reste du code (en gros)
<CODE>
 
using namespace std;
 
 
static int sauver(char* chemin, char* vecteurChemin, char* vecteurSection, char* vecteurProfil)  
{}
 
static int sauverVRML(char* chemin, char* listePoints, char* listeFaces)  
{}
 
static int chargerVRML(char* chemin, char* listePoints, char* listeFaces)  
{}
 
static int charger(char* chemin, char* vectChemin, char* vectSection, char* vectProfil )
{}
 
extern "C"
char *query(void)  
{
  return "ES_VRML";
}
 
extern "C"
int run(char* arguments[])  
{
  ActionPluginVRML* action = (ActionPluginVRML*) arguments[0];
 
  switch(*action){
  case Sauver:
    sauver(arguments[1], arguments[2], arguments[3], arguments[4]);
    break;
  case SauverVRML:
    sauverVRML(arguments[1], arguments[2], arguments[3]);
    break;
     
  case Charger:
    charger(arguments[1], arguments[2], arguments[3], arguments[4]);
    break;
 
  case ChargerVRML:
    chargerVRML(arguments[1], arguments[2], arguments[3]);
    break;
  }
 
  return EXIT_SUCCESS;
}
 
<\CODE>
 
voilà...
bon je continue mes investigations. J'ai l'impression que le problème vient des Makefiles.
Merci beaucoup de m'avoir répondu

si ca plante au dlopen et pas au dlsym c'est parce que je met le flag RTLD_NOW. Si je l'enleve et que ça plante dans le dlsym, j'ai une chance d'en savoir plus sur l'erreur?

Probablement pas.
 
Mais tu n'as pas répondu à ma question: le code que tu as posté se trouve-t-il tout entier dans le .h ?

Ou plus simple, que donne:
nm Plugins/ES_VRML.plg | grep EnsembleDePoints

non, c'était le code .cpp du plugin pas de .h pour le pulgin.
sinon:
nm Plugins/ES_VRML.plg | grep EnsembleDePoints
donne:
 
  U _ZN16EnsembleDePoints12insererEnFinERK7Point3D
         U _ZN16EnsembleDePoints7effacerEv
         U _ZNK16EnsembleDePoints12nombrePointsEv
         U _ZNK16EnsembleDePoints12obtenirPointEi

tu as l'air d'y comprendre qq chose : je suis admirative!

U comme undefined, je rêve pas.
 
Il faut donc que tu compile ton .cpp, et que tu inclues dans ton plug-in le(s) .o généré(s). C'est ça qui manque.

dans le makefile de l'éxécutable, le .o du plugin est "remonté", ca revient pas au même que "descendre" les .o ?
 sinon je n'ai jamais inclu de .o dans un .cpp... je pense que je n'ai pas bien compris, tu veux bien réexpliquer?
missi

Tu n'as pas l'air d'avoir compilé la classe EnsembleDePoints. C'est probablement une erreur dans le makefile.
Que veux-tu dire par "remonter" et "descendre" ?

Merci pour vos réponses... je n'ai pas trouvé le problème mais à force de reprendre mes sources de la version précédente, ben ça marche, c'est hyper frustrant! je ne saurai jamais d'où ça venait. (comme toi el muchacho et mon prof,je pense que ça venait du makefile...)
Remerci!
je suis éjà sur un nouveau bug..
mais celui là, je me le garde!
 
Allez bye les harders!