Librairie dynamique et linker

Librairie dynamique et linker - C++ - Programmation

Marsh Posté le 20-03-2015 à 16:12:36    

Hello :hello:

 

Je suis en train de me former au c++ (ça ne se fait pas sans maux de crâne...) depuis quelques mois maintenant après avoir fait pas mal de PHP (je vois d'ici ceux qui grincent des dents... :whistle:) qui a perdu de sa valeur à mes yeux depuis que j'ai commencer à goûter au C/C++ Il m'a fallut du temps pour chasser de mauvaises habitudes de conception incompatibles avec ce nouveau langage.

 

Pour ce faire j'ai décidé de faire un petit jeu simpliste, jouable en command line, ça à l'avantage de ne demander que des mécaniques de bases et d'attaquer les choses une par une.
Même si je suis encore (très ?) loin d'avoir un niveau convenable (manque de connaissance de la libc, du système, ...) j'ai déjà fait une version qui fonctionne.

 

Maintenant que je me sens à l'aise avec la base (syntaxe, compiler et surtout minimum de niveau de débogage) je m'attaque au linker. Et je me doute que ce n'est pas facile.
L'idée est de mettre en module les actions de mon petit jeu (via dlopen/dlsym/dlclose)

 

Je pense que je me heurte a un problème conceptuel, quelque chose qui m'échappe: j'ai bien pigé l'utilisation de "extern" du côté de la librairie pour exposer ses fonctions. En revanche je pense qu'il me manque quelque chose.
Je vais essayer de prendre un exemple con.

 

Application de base "core.hpp"

Code :
  1. class game_action {
  2. virtual bool isAllowed();
  3. virtual void execute();
  4. }
  5. class core {
  6.   /* ... */
  7. }
 

Et une class de module "custom_module.hpp":

Code :
  1. #include "core.hpp"
  2. class module_custom_action_1 : public game_action {
  3. bool isAllowed();
  4. void execute();
  5. }
  6. class module_custom_action_2 : public game_action {
  7. bool isAllowed();
  8. void execute();
  9. }
 

core.cpp compile sans problème. de la même manière custom_module.cpp aussi. Mais lorsque je charge mon .so depuis l'application principale j'ai des problèmes de symbole game_action non définit, ce a quoi je m'attendais.
Je me dis aussi que compiler custom_module.cpp avec core.cpp n'est pas non plus la bonne solution.
Le module est dépendant de l'application principale, et l'application est indépendante du module

 

Peut-être que je ne suis pas du tout sur la bonne voie, je cherche à comprendre. J'ai trouvé plein de liens sur le chargement des librairies, mais aucun qui m'explique a quoi je fais face, à dire vrai je ne sais trop quoi chercher.
Donc plutôt que de me donner la réponse (A moins qu'elle soit vraiment évidente) si vous connaissez un bon tutorial ou article qui m'éclairerait à y voir plus clair... Ca ne sera pas le premier, ni le dernier !

 

Je sais qu'il y a du monde sur ce forum qui pourra m'aider !

 

Merci à ceux qui auront pris le temps de lire mon petit pavé :jap:


Message édité par the_bigboo le 23-03-2015 à 12:27:21
Reply

Marsh Posté le 20-03-2015 à 16:12:36   

Reply

Marsh Posté le 20-03-2015 à 16:38:26    

Il faut que tu exporte tes classes (code spécifique gcc dans ce cas, ces macros dépendent du compilateur) :

 
Code :
  1. // Lors de l'export
  2. class __attribute__((visibility("default" ))) MyClass
  3. { ... }
  4. // Lors de l'import
  5. class __attribute__((visibility("hidden" ))) MyClass
  6. { ... }
 

Le mieux, c'est de passer par des macros (mettons tu mets ça dans ModuleApi.hpp)

 
Code :
  1. #if defined(MODULE_API_EXPORT)
  2.   #define MODULE_API __attribute__((visibility("default" ))
  3. #else
  4.   #define MODULE_API __attribute__((visibility("hidden" ))
  5. #endif
 

et du coups, le code te donne ça :

 
Code :
  1. #include "ModuleApi.hpp"
  2. class MODULE_API MyClass
  3. {
  4. //...
  5. };
 

Du coups, lorsque tu compile ton programme, si tu as un #define MODULE_API_EXPORT (tu le défini dans les options de compils, gcc -dMODULE_API_EXPORT de tête), ça exportera tes classes (lorsque tu veux pondre ton fichier so).
Par contre, ça te fera pas du code utilisable par le C dans ce cas.
Si tu veux faire ça, il faut faire :

 
Code :
  1. extern "C"
  2. {
  3. // les fonctions
  4. }


ça formattera les symboles de manière générique, mais forcément ça ne fonctionne pas avec les classes.


Message édité par Terminapor le 20-03-2015 à 16:38:54

---------------
Perhaps you don't deserve to breathe
Reply

Marsh Posté le 20-03-2015 à 17:12:54    

Hello ! Merci de ta réponse !
 
Effectivement, je pensais bien à un truc dans ce genre là.
Je vais regarder ! Merci !
 
Pour info, je suis sur un GNU GCC 4.9.2 (le dernier normalement)
Est-ce que cette façon de procéder à un nom ?

Reply

Marsh Posté le 20-03-2015 à 17:37:27    

Quelle façon de procéder ? Déclarer des macros ?


---------------
Perhaps you don't deserve to breathe
Reply

Marsh Posté le 20-03-2015 à 18:15:39    

Je pense que j'ai posé une question sans intérêt u__u
Ya plus qu'a comme on dit ^^

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed