Re: [PROG] dlsym et les objets

Xavier Sirvent wrote:

> Xavier Sirvent wrote:
>
>> Dans un programme, j'ai besoin de charger explicitement des libraires
>> .so
>> Pour cela, j'utilise la fonction dlopen().
>> Ensuite, j'ai besoin de trouver les adresses des fonctions qui
>> m'intéressent et j'utilise dlsym(). Tant que j'utilise des fonctions
>> extern "C", j'arrive sans problème à trouver le pointeur sur mes
>> fonctions.
>>
>> Maintenant, j'essaie d'ajouter un soupçon d'objet dans mes
>> librairies. Mes librairies contiennent maintenant
>> des classes qui sont des singleton (la classe C a donc une méthode
>> statique : C* instance() )
>>
>> Ai-je un moyen d'accéder a mes méthodes instance() qui ne sont pas
>> extern "C" mais quand même statiques???
>>
> Je précise quand même que le moyen qui consiste à ajouter à la
> librairie une méthode extern "C"
> qui ferait un new de mon objet puis qui me renverrait le pointeur sur
> l'objet créé fonctionne mais ne me convient pas:
> J'aimerais bien ne pas passer par une fonction extern "C" mais rester
> tout le temps en "C++".
>
>> De manière plus générale, y a-t-il des moyens de manipuler
>> dynamiquement des librairies de classes plutôt que des librairies de
>> fonctions?
>

Comme son nom l'indique "dlsym" sert a charger un symbole, non une
fonction & encore moins une classe ou un objet. Il te faut donc
rechercher les symboles par leur nom binaire, tel que ceux fournis par
"nm". Si C++ a juge bon de ne pas utiliser les noms de fonction /
variables[1] pour generer les symboles, mais des versions "manglee",
c'est son probleme, pas celui de dlsym.

nm <ta librairie> | grep <ta fonction>

La solution a ton probleme est de declarer (je n'ai pas dit "definir")
un point d'entree en "extern C", afin que le symboles associe ne soit
pas "mangle" par le compilateur C++.

La _mauvaise_ solution a ton probleme consiste a rechercher avec dlsyms
le nom de symbole -- tel que fourni par nm. Mauvaise, car un changement
de prototype de cette fonction occasionnera du meme coup un changement
du symbole & donc la mise en panne de ton chargeur dynamique. Mauvaise
aussi car en ces temps troubles de passage de gcc-2.x a gcc-3.2 (en
passant par gcc-3.0), les ABI (entends "le moteur de mangling des
symboles") sont incompatibles d'un compilateur au l'autre.

En bref: quand on commence a jouer avec les symboles, hors de "C" -- qui
ne "mangle" rien -- point de salut.

-- FiX

[1] Intention louable au demeurant: la verification des prototypes
d'appel a l'etape de l'edition de liens.

--
Francois-Xavier 'FiX' KOWALSKI