Création de .dll / .so en C++ - Page 1

Dans une bibliothèque dynamique écrite en C++, est-ce qu'il est possible d'exporter plusieurs fonctions ayant le même nom ou pas (des fonctions surchargées par exemple) ? Et plusieurs fonctions ayant la même signature, mais provenant de classes différentes ?

Et si la surcharge de fonctions est possible, comment on peut les différencier, au chargement ?

Merci.

en principe une fonction C++ a, du point de vue du C/asm/etc, un nom "décoré", c'est a dire qu'il contient toutes les informations de type utile (genre, "int mafonction(class Foo foo,class Bar bar)" devient "@@Gjiroejgioij@mafonction@ZJIOFVFoo@ZJIOFVBar"). je sais pas comment ca se passe pour les libs dynamiques, mais a priori si tu as une fonction de chargement qui attend un nom de fonction C, il doit falloir que tu lui passes le nom décoré a la place... et évidemment la méthode de décoration dépend de l'ABI choisie, ce serait pas drole sinon

(et non, ca répond pas a la question )

OK, donc il vaut mieux que j'exporte des fonctions C.
Merci.

pas forcément, le linker sait probablement exporter les fonctions comme il faut (pour ca faut attendre qqun qui a déja fait ce genre de choses)
cela dit il y a quand meme le probleme que l'ABI C++ est un peu moins standard entre les différents compilos... tout dépend de l'utilisation que tu veux en faire ^^

En fait, de toute façon ça n'a pas d'importance de pouvoir surcharger les fonctions et ce n'est pas très grave si le nom du scope n'est pas conservé donc je peux me débrouiller en exportant en C.

C'est pour faire des plugins en fait. Les dll/so stockent le code des fonctions du plugin, et mon application charge les plugins ensuite, à travers une classe qui sert de wrapper.

ben l'avantage si tu fais une interface en C, c'est qu'on peut aussi s'en servir en C donc oui c'est une meilleure idée ^^

OK merci.

Sinon, j'ai un petit problème : les plugins sont dans le sous-répertoire "plugins" par rapport au répertoire où l'application sera installée, mais je ne sais pas comment retrouver ce répertoire à partir de mon programme. Si le programme est lancé alors que le répertoire courant est celui où est installée l'application, il n'y auura pas de problème, mais s'il est lancé avec comme répertoire courant un autre répertoire, je ne sais pas comment faire pour retrouver le répertoire d'installation (qui peut varier d'un utilisateur à l'autre).
Je peux éventuellement, dans le programme d'installation écrire dans un fichier de config ou la base de registres (sous win) le chemin du répertoire d'installation, mais s'il y a une solution plus simple...

Normalement, argv[0] contient un chemin vers l'exécutable (au moins relatif).

Ensuite, il ne reste plus qu'à enlever tous les caractères après le dernier '/' (ou '\' sous windows) de la chaîne et tu as un chemin vers le dossier de l'application qui devrait fonctionner avec les fstream, non ?

Hmm, pour une dll c'est plus hardu qu'un *.exe... Je me souviens avoir cherché quelque peu quand j'avais créé ma dll mIRC et je crois qu'après recherches j'avais opté pour la solution "bourrin" -> Tant pis si ça trouve pas.
De plus la méthode doit énormément varier d'un OS a l'autre ^^
Sous windows je crois que tu pourrais regarder la fonction FinFile/FindFileEx (si c'est bien comme ça qu'elle s'apelle, j'arrive plus a la retrouver)

BiHi> sur les windows qui n'utilisent pas DOS il faut aussi rechercher dans le PATH...


hmm sinon j'ai ca dans GTC mais c'est tres incomplet (par exemple sous Unix on peut avoir un PATH sous la forme /bin:/usr/bin/:"/ceci/est/un:chemin/avec/des/deux:points":/usr/loca/bin, mais j'ai pas géré le cas ou les : sont dans des guillemets et tous les trucs d'échappement qu'il faut quand il y a des guillemets; ou sous Windows on peut avoir des / ou \ en tant que séparateur dans argv[0], mais seul le \ est parsé), donc je sais pas si ca t'intéresse ou pas...

Sasume
: je ne sais pas comment retrouver ce répertoire à partir de mon programme

Sous Linux : readlink /proc/self/exe

Merci pour vos réponses. Je cherche une solution la plus portable possible, au fait j'utilise Qt, peut-être qu'il y a déjà quelque chose qui permet récupérer ça facilement avec Qt ?

nitro> Ta solution marche-t-elle sur tous les systèmes unix ? (par exemple MacOS X)

Après quelques recherches, effectivement, Qt fournit 2 fonctions intéressantes : QApplication::applicationDirPath() qui retourne le chemin vers le dossier qui contient l'exécutable, et QApplication::applicationFilePath() qui retourne le chemin vers l'exécutable lui-même.
Donc à priori c'est bon, mon problème est résolu

Oué, ben en fait ce que fait Qt sous *nix, c'est la bidouille avec argv[0]
Sous windows, il me semble que Qt utilise GetModuleFilename ou une fonction du genre (dsl ça commence à dater la dernière fois que j'ai codé sous dows)

J'ai réussi à compiler mon fichier c++ en une DLL grâce à la doc de MSDN, mais maintenant quand j'essaie de la charger, je vérifie préalablement qu'elle exporte bien les fonctions prévues, et je ne les trouve pas !
J'utilise l'API QLibrary de Qt, qui ne me permet pas de svaoir quels sont les symboles exportés, mais seulement de savoir si tel symbole est exporté. Moi j'aimerais savoir quels symboles sont exportés par ma DLL, afin de voir où se situe mon problème. Pouvez-vous m'aider ?

J'immagine que ton problème se situe au niveau de la décoration des noms qui ne doit pas être la même ^^
Sous windows tu as DbgHelp (Debug Help Library) ou ImgHelp (Version avant DbgHelp, regarde là si DbgHelp n'est pas suffisant) qui te permet d'obtenir des informations sur les fonctions exportées et qui te permet de lire les prototypes ou nom de fonctions (plusieurs options dispo) a l'aide de UndecorateSymbolName. (Pour les apps C++ compilées avec Visual C++)
Si ton app est compilée avec un autre compilo, bah faut chercher comment il décore les noms si ce n'est pas géré nativement par Qt
Sinon, pour voir manuellement ce qui est exporté il y a le très bon Dependency Walker qui est un outil indispensable pour programmer (ou pour d'autres activités proches) sous Windows

Sasume
: nitro> Ta solution marche-t-elle sur tous les systèmes unix ? (par exemple MacOS X)

Non, /proc est spécifique à Linux. Il y a sans doute quelques Unix qui font pareil, mais pas Mac OS X.

Moi j'aimerais savoir quels symboles sont exportés par ma DLL, afin de voir où se situe mon problème. Pouvez-vous m'aider ?

GoldenCrystal te donne la solution pour Windows (j'imagine que c'est ce que tu veux, vu que tu parles de MSDN et de DLL), mais si jamais tu veux la même chose sous Linux, man nm (-C pour interpréter le mangling).

Merci à vous.
J'ai regardé avec Dependency Walker, et il semble que mes symboles sont bien exportés (et je les exporte "en C" donc, ils ne sont pas décorés). Je ne sais donc pas d'où vient mon problème. Je trouverai bien...

Euh... En C sous Windows, le symbole a au moins une décoration, le _ qui le précède...
Et si les fonctions sont en __stdcall (comme les fonctions avec le modificateur WINAPI ou CALLBACK), il y a en plus derrière un @ et la taille totale en octets des prarmètres...

Un bon moyen sous VC++ est de cocher l'option du projet "generate mapfile" (elle doit être dans l'onglet Link), puis en ouvrant le fichier .map, tu auras tous les noms de fonctions C.

Un autre moyen c'est d'utiliser le dependency walker hein
Sinon les ficheirs .def sont utiles pour choisir ses noms aussi

Oui, mais je ne sais pas comment on les crée . MSDN les évoque partout dans le chapitre des DLL, mais je ne sais même pas quelle forme ils sont censés avoir...

Beuh ils font pas que les évoquer, ils sont aussi expliqués hein (bien sûr MSDN en local on trouve + facilement, mais le contenu du site reste le même)
En plus ça ne se trouve certainement pas que sur MSDN :]