Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
929 connectés 

  FORUM HardWare.fr
  Programmation
  C++

  Librairie dynamique et linker

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Librairie dynamique et linker

n°2253792
the_bigboo
Posté le 20-03-2015 à 16:12:36  profilanswer
 

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
mood
Publicité
Posté le 20-03-2015 à 16:12:36  profilanswer
 

n°2253803
Terminapor
I'll see you rise.
Posté le 20-03-2015 à 16:38:26  profilanswer
 

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
n°2253808
the_bigboo
Posté le 20-03-2015 à 17:12:54  profilanswer
 

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 ?

n°2253811
Terminapor
I'll see you rise.
Posté le 20-03-2015 à 17:37:27  profilanswer
 

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


---------------
Perhaps you don't deserve to breathe
n°2253816
the_bigboo
Posté le 20-03-2015 à 18:15:39  profilanswer
 

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


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C++

  Librairie dynamique et linker

 

Sujets relatifs
Alias/Versions multiples d'une librairieDifficultés création de graphique croisé dynamique VBA
Recupération de chk dynamiqueUtilisation de librairie C avec node.js
IHM d'une application VCL paramétrable par l'utilisateur ?Comment wrapper des fonctions dans une librairie statique de Windows?
Insertion dynamique & gestion de la position dans la pagepositionner un menu dynamique
VBA. Nom de Tableau dynamique.librairie CImg : créer une image à partir d'une matrice
Plus de sujets relatifs à : Librairie dynamique et linker


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR