Comment lier l'interface C d'une lib en C++?

Je veux compiler avec ICL (Intel C++ Compiler) l'interface C de ma bibliothèque C++, afin que d'autres personnes puissent utiliser cette librairie avec d'autres compilateurs sous Windows (VC8, Cygwin GCC...)

Donc certains de mes fichiers d'en-tête ont la structure suivante

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

#ifdef __cplusplus // code C++: déclaration de classes, fonctions templates... ... #endif __cplusplus   #ifdef __cplusplus extern "C" { #endif // Déclaration des fonctions C de l'interface ... #ifdef __cplusplus } #endif

---

Je compile le fichier .LIB avec ICL, mais je n'arrive pas à le lier avec l'interface C sous VC8 comme je le souhaiterais.

Dans mon programme utisateur ,j'essaye
1)

Code:

---

1 2 3 4

extern "C" { #include "ma_lib.h" }

---

Mais alors le compilo de VC8 répond que:
> ma_lib.h : error C2894: templates cannot be declared to have 'C' linkage
Donc le compilo va malheureusement vérifier le code C++ dans le fichier d'en-tête.

2)

Code:

---

1 2	#include "ma_lib.h"

---

Mais le linker de VC8 répond qu'il ne peut ouvrir des LIB C++ dont ma librairie est dépendante, par example:
> fatal error LNK1104: cannot open file 'libmmt.lib'
(libmmt est la librairie mathématique d'ICL)

Alors que je ne veux utiliser que les fonctions C de ma librairie, et éviter de donner toutes les autres librairies dont elle est dépendante. Que faire?

Si vous avez des precisions sur les mécanismes de décorations et des dépendances des librairies qui me permettraient de comprendre le problème, je suis preneur.

Tu devrais faire un fichier d'en-tête en C tout court, sans tes templates ni rien et un fichiers d'en-tête avec juste les templates.
Ainsi quand tu voudras accéder aux fonctions C, tu inclueras la première et pas de pb de décoration des noms, et si tu peux utiliser la partie C++ de ta bibliothèque, tu en profites ;)

Je viens d'essayer.
Ca resoud bien le 1er problème, mais VC8 me demande toujours les librairies C++ dont ma librairie est dépendante, mais que les fonctions C n'appellent pas.
Une idée?

Ben je ne vois pas le problème pour ça: Il te suffit de lier avec les librairies en question...

Citation:

---

Envoyé par Charlemagne

Je viens d'essayer.
Ca resoud bien le 1er problème, mais VC8 me demande toujours les librairies C++ dont ma librairie est dépendante, mais que les fonctions C n'appellent pas.
Une idée?

---

Pas normal, sauf si dans tes fonctions C inlinées, tu fais appel à des fonctions C++.

Citation:

---

Ben je ne vois pas le problème pour ça: Il te suffit de lier avec les librairies en question...

---

J'aimerais éviter de les lier pour simplifier et pour ne pas avoir à donner la demi douzaine de librairies annexes.

Certes, ça marche sous VC8 quand ma librairie est compilée avec ICL, mais je doute que ça marche encore avec GCC sous cygwin.

Citation:

---

Pas normal, sauf si dans tes fonctions C inlinées, tu fais appel à des fonctions C++.

---

Les fonctions C ne sont pas inlinées.
Les fonctions C font appel à des fonctions C++, c'est l'intérêt de l'interface C.

Et donc je comprends franchement pas pourquoi les dépendances C++ sont écrites dans ma librairie compilée, a fortiori pour son interface C.

C'est une bibliothèque statique ou dynamique, l'interface ?

Citation:

---

C'est une bibliothèque statique ou dynamique, l'interface ?

---

Statique (.LIB)
Statique/Dynamique, ça fait une différence?
J'y connais pas grand chose, mais l'interface d'une DLL est forcé d'être en C, non?

Citation:

---

Envoyé par Charlemagne

Les fonctions C ne sont pas inlinées.
Les fonctions C font appel à des fonctions C++, c'est l'intérêt de l'interface C.

Et donc je comprends franchement pas pourquoi les dépendances C++ sont écrites dans ma librairie compilée, a fortiori pour son interface C.

---

Ben, si tes fonctions C font appel à tes fonctions C++ qui font appel aux fonctions de ces librairies, c'est normal qu'au bout du compte tu aies besoin des librairies en question...

Citation:

---

Ben, si tes fonctions C font appel à tes fonctions C++ qui font appel aux fonctions de ces librairies, c'est normal qu'au bout du compte tu aies besoin des librairies en question...

---

T'as peut-être bien raison. :(
Je trouve quand-même bizarre que ma librairie compilée se rappelle des librairies qui étaient compilées avec elle et en impose la présence lors de l'édition de lien du programme.
Aucun moyen de tout réunir dans une seule librairie, pour que la mienne n'ait plus de dépendances?

Citation:

---

Je trouve quand-même bizarre que ma librairie compilée se rappelle des librairies qui étaient compilées avec elle et en impose la présence lors de l'édition de lien du programme.

---

Non, c'est toujours le cas pour les bibliothèques statiques. Pas trop le choix.

Citation:

---

Envoyé par Charlemagne

Statique (.LIB)
Statique/Dynamique, ça fait une différence?
J'y connais pas grand chose, mais l'interface d'une DLL est forcé d'être en C, non?

---

Voilà, c'est là le pb, je pense. Les bibliothèques statiques ne font pas de résolution des liens complète, c'est lors de l'édition des liens avec la bibliothèque statique que les liens vers les autres fonctions sont cherchées, donc ça pose problème.

Citation:

---

Non, c'est toujours le cas pour les bibliothèques statiques. Pas trop le choix.

---

Citation:

---

Voilà, c'est là le pb, je pense. Les bibliothèques statiques ne font pas de résolution des liens complète, c'est lors de l'édition des liens avec la bibliothèque statique que les liens vers les autres fonctions sont cherchées, donc ça pose problème.

---

Donc y'a pas d'autres solutions que de lier avec toutes les librairies statiques dépendantes.
Mais ça marcherait avec une DLL?

Comment on fait une DLL? comme pour une librairie statique sauf qu'on change le projet de Visual?
Comment on fait pour appeler les fonctions d'une DLL à partir d'un programme?

Citation:

---

Mais ça marcherait avec une DLL?

---

Oui.

Citation:

---

Comment on fait une DLL? comme pour une librairie statique sauf qu'on change le projet de Visual?

---

Oui (Options du projet -> Général -> Configuration type).
De plus, il faudra explicitement définir quelles fonctions / classes tu voudras exporter (la méthode dépendant du système).

Citation:

---

Comment on fait pour appeler les fonctions d'une DLL à partir d'un programme?

---

Si tu lies avec le .lib, rien de spécial à faire.
Si tu charges ta DLL dynamiquement, il faut récupérer les fonctions que tu veux appeler avec GetProcAddress (sous Windows), dlsym (sous Linux) ou mac_getBundleSym (sous MacOS). Bref je pense que tu vas lier avec le .lib :)

Citation:

---

Si tu lies avec le .lib, rien de spécial à faire.

---

Enfin, il faut quand même savoir les déclarer...

Généralement sous Windows, on emploie le même fichier d'en-tête pour compiler et utiliser la bibliothèque : Celui généré par Visual quand on crée un projet DLL (si tu n'as pas visual ou si tu as Visual express (qui, si j'ai bien compris, ne crée pas directement de projet DLL) il doit y avoir un aperçu du fichier dans la FAQ, sinon je peux poster un squelette...)

Citation:

---

Si tu charges ta DLL dynamiquement, il faut récupérer les fonctions que tu veux appeler avec GetProcAddress (sous Windows), dlsym (sous Linux) ou mac_getBundleSym (sous MacOS). Bref je pense que tu vas lier avec le .lib

---

Ca me paraît bien compliqué tout ça, et en plus c'est dependant du système.
Je me demande effectivement si ça en vaut le coup, a priori non.
J'ai toujours détesté les problèmes informatiques du genre.

Par acquis de conscience, comment on fait pour définir les classes/fonctions apartenant à la DLL. C'est possible d'exporter des classes? je pensais qu'une DLL ne contenait que des fonctions C?

J'ai essayé vite fait de compiler ma librairie en DLL, mais l'édition de lien échoue car il faut en plus que je recompile STLport dynamiquement...

Citation:

---

Généralement sous Windows, on emploie le même fichier d'en-tête pour compiler et utiliser la bibliothèque : Celui généré par Visual quand on crée un projet DLL (si tu n'as pas visual ou si tu as Visual express (qui, si j'ai bien compris, ne crée pas directement de projet DLL) il doit y avoir un aperçu du fichier dans la FAQ, sinon je peux poster un squelette...)

---

Je veux bien des explications et un squelette, merci.
Je vais voir aussi dans la FAQ

Généralement, le fichier d'en-tête d'une bibliothèque exoportant des fonctions avec interface C est ainsi (on suppose que la bibliothèque s'appelle MaDll):

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

//MADLL_EXPORTS est défini dans les options de compilation //du projet MaDll et n'est jamais défini ailleurs. #ifdef MADLL_EXPORTS #define MADLL_API __declspec(dllexport) #else #define MADLL_API __declspec(dllimport) #endif   //Les fonctions qui suivent sont soit en C, //soit en C++ défini avec extern "C".   #ifdef __cplusplus extern "C" { #endif   MADLL_API void UneFonction(); MADLL_API int UneAutreFonction(char const *str);   #ifdef __cplusplus } #endif   //Si la DLL exporte des fonctions/classes C++ (oui, c'est possible) : #ifdef __cplusplus   MADLL_API class UneClasse { public: int UneFonctionMembre(); };   #endif

---

Ce header peut être utilisé par la DLL pour la compiler (les fonctions et classes seront déclarées en __declspec(dllexport)) et par le programme utilisateur pour l'utiliser (les fonctions et classes seront déclarées en __declspec(dllimport)).

Une DLL peut tout à fait exporter des classes et fonctions C++ sans extern"C", mais il me semble que les décorations C++ sont propriétaires : Je ne suis pas certain que les fonctions C++ d'une DLL compilée avec Visual puissent être utilisées par un programme C++ compilé avec mingW...

Les fonctions avec une interface C (fonctions C ou C++ extern"C") sont par contre parfaitement utilisables par tous les programmes Win32 quelque soit le compilateur employé...

Ca a pas l'air si compliqué que ça (quand on sait).
J'ai rien vu sur les librairies dynamiques dans la FAQ.

Y'a du changement dans l'air pour ma librairie.
Je crois que je vais (essayer de) faire une DLL avec un interface minimum.

A priori en changeant la macro MADLL_API, il devrait être possible d'adapter la syntaxe pour d'autres compilos (je pense surtout à GCC), non?

Sans doute (déjà, __declspec(dllexport) est supporté par mingW) mais je ne connais pas la syntaxe pour faire des bibliothèques dynamiques pour les unixoïdes.
Egalement, l'emplacement n'est pas forcément le même dans la déclaration...

OK
Merci à tous.
Je vais tâcher de faire une DLL.

Tu peux regarder ce fichier de configuration de la bibliothèque Ogre par exemple, et regarder comment ils déclarent la macro _OgreExport selon les différents systèmes :
http://www.ogre3d.org/docs/api/html/...8h-source.html

Citation:

---

Tu peux regarder ce fichier de configuration de la bibliothèque Ogre par exemple, et regarder comment ils déclarent la macro _OgreExport selon les différents systèmes

---

Ca va aider, mais on y voit que GCC (version antérieure à 4) n'accepte pas de syntaxe similaire à Windows. Donc je vois pas comment on y fait des librairies partagées. Mais l'important pour moi c'est Windows.

J'ai créé ma petite DLL, mais j'ai déjà un 1er problème: j'arrive pas à la lier au programme.
J'aimerais éviter l'édition de lien implicite (GetProcAdress) car j'ai vu dans la doc de Visual, qu'il y a la possibilité plus facile d'une édition de lien implicite.

Citation:

---

To implicitly link to a DLL, executables must obtain the following from the provider of the DLL:
-A header file (.H file) containing the declarations of the exported functions and/or C++ classes.
-An import library (.LIB files) to link with. (The linker creates the import library when the DLL is built.)
-The actual DLL (.DLL file).
Executables using the DLL must include the header file containing the exported functions (or C++ classes) in each source file that contains calls to the exported functions. From a coding perspective, the function calls to the exported functions are just like any other function call.

To build the calling executable file, you must link with the import library. If you are using an external makefile, specify the file name of the import library where you list other object (.OBJ) files or libraries that you are linking with.

---

C'est bien joli tout ça, mais je vois pas de fichier .LIB (import library) créé en même temps que la DLL, comme le suggère pourtant la doc de Visual.
Des idées?

En fait, pour GCC, les fonctions sont exportées par défaut, il n'y a pas d'import/export à faire.

1. GetProcAddress(), c'est EXplicite.
2. Quelles sont tes options de compilation? regarde si tu n'as pas oublié d'en activer une... (genre "import library" à activer ou "doesn't produce .lib" à supprimer)

Edit: Sous visual 2005 pro, j'ai l'option Project Properties->Configuration Properties->Linker->Advanced->Import Library

Ca c'est de la réponse rapide. :D Merci

Je comprends pas, ça marche maintenant, le linker me crée bien un '.dll' ET un '.lib'.
J'avais juste vérifié dans le projet si l'option 'Import Library' était correcte, et elle l'était: "$(OutDir)/$(TargetName).lib". Je touche du bois...

Ca marche nickel avec une DLL: plus de dépendance, et pas de changement majeur dans le code source grâce à l'édition de lien implicite.

J'ai rajouté ceci dans l'entête de configuration

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

#if defined(__ICL) || defined(_MSC_VER)   //#define MALIB_API // pour compiler/utiliser la librairie statique   #ifdef MALIB_EXPORT // à définir uniquement dans le projet/makefile #define MALIB_API __declspec(dllexport) // pour compiler en DLL #else #define MALIB_API __declspec(dllimport) // pour utiliser la DLL #endif   #elif defined (__GNUC) #define MALIB_API #endif

---

Je coupe les cheveux en 4, mais j'ai encore 2 petites questions:

- Y a t-il un moyen de reconnaître automatiquement (avec un #ifdef ?) , si le projet compile une DLL ou une LIB? Ca m'éviterait d'avoir à modifier manuellement l'entête de configuration à chaque changement de projet.

- Il faut que l'exécutable trouve la DLL. A ma connaissance, il faut donc que la DLL soit dans le même répertoire que l'executable ou bien dans l'un des répertoires du PATH. Mais ni l'un ni l'autre n'est pratique parce que la DLL est créée dans les répertoires MaLib/release ou MaLib/debug, et parce que j'ai plusieurs programmes qui utilisent la DLL. Y'a pas un moyen plus pratique pour que les executables trouve leur bonne (debug/release) DLL? et donc sans avoir à déplacer manuellement la DLL dans chaque répertoire des exécutables.

Citation:

---

- Y a t-il un moyen de reconnaître automatiquement (avec un #ifdef ?) , si le projet compile une DLL ou une LIB? Ca m'éviterait d'avoir à modifier manuellement l'entête de configuration à chaque changement de projet.

---

Non. Par contre il vaut mieux définir le symbole dans les options du préprocesseur plutôt que dans le code source.

Citation:

---

- Il faut que l'exécutable trouve la DLL. A ma connaissance, il faut donc que la DLL soit dans le même répertoire que l'executable ou bien dans l'un des répertoires du PATH. Mais ni l'un ni l'autre n'est pratique parce que la DLL est créée dans les répertoires MaLib/release ou MaLib/debug, et parce que j'ai plusieurs programmes qui utilisent la DLL. Y'a pas un moyen plus pratique pour que les executables trouve leur bonne (debug/release) DLL? et donc sans avoir à déplacer manuellement la DLL dans chaque répertoire des exécutables.

---

Pas à ma connaissance. Par contre selon ton environnement, tu peux ajouter un PATH temporaire pendant l'exécution de tes projets qui requierent la DLL, ou encore faire un .bat qui copie la DLL où il faut, et exécuté automatiquement en étape de post-build.

Je m'en doutais un petit peu...
Encore merci

J'ai parlé trop vite, car finallement le problème reste entier.
La DLL n'a certes pas de dépendances, mais la librarie d'importation en a.
Je ne m'en suis pas rendu compte sur le coup car je travaille sous le même environnement (et les paths rendaient le problème transparent).

A moins de se passer de la librairie d'importation, avec des appels explicites à la DLL, je vois pas comment faire. Mais la syntaxe des appels explicites (GetProcAdresse) me paraît tellement contraignante que je désire à tout prix l'éviter.

Des idées?

Normalement ça ne devrait pas être le cas. Les bibliothèques statiques devraient être compilées dans ta DLL et ne plus t'embêter. Peut-être une option de compilation à bidouiller ?

Ca se complique.
Je cerne un peu mieux le problème, mais c'est pas encore ça

En fait j'utilise STLport pour compiler ma librairie, car d'après mes tests (qui datent certes un peu), celle-ci est plus rapide avec le compilo ICL que les STLs de VC ou de GCC pour les calculs mathématiques (en particulier sur les nombres complexes). Bref, j'utilise une librairie (statique ou dynamique, c'est selon) pour STLport.

Je me mets dans la peau d'un utilisateur lambda, sans STLport mais utilisant la STL intégrée à Visual.Je réussis à lier mon programme avec ma DLL, mais son lancement m'annonce qu'il lui faut impérativement la DLL de STLport. Donc il y a dorénavant une dépendance dynamique (alors que la dépendance était auparavant statique avec les LIB)

En plus, STLport à un comportement inhabituel pour lier la librairie (statique ou dynamique). Il n'est pas besoin de rajouter la dépendance dans l'édition de liens du projet comme d'hab.
En fait il y a a qq part dans un '.h' de STLport une instruction pour importer la bonne librairie. (j'ai pas encore dénicher l'endroit dans le code. Vu que je connais pas l'instruction, c'est pas facile à trouver)
Ca me laisse penser qu'il existe bien une possibilité, pour faire en sorte que le code C++ sache si le compilo est en mode statique ou dynamique)

J'ai raison?
Des pistes?

Citation:

---

Envoyé par Charlemagne

Ca se complique.
Je cerne un peu mieux le problème, mais c'est pas encore ça

En fait j'utilise STLport pour compiler ma librairie, car d'après mes tests (qui datent certes un peu), celle-ci est plus rapide avec le compilo ICL que les STLs de VC ou de GCC pour les calculs mathématiques (en particulier sur les nombres complexes). Bref, j'utilise une librairie (statique ou dynamique, c'est selon) pour STLport.

Je me mets dans la peau d'un utilisateur lambda, sans STLport mais utilisant la STL intégrée à Visual.

---

Donc, au final, dans le programme, std::complex vaudra des choses différentes selon là où on se trouve ? C'est une violation de l'ODR, ce qui est un comportement indéfini. En pratique, pour ce genre de manip, il faut surtout éviter par dessus tout que des variables de tous ces types soient passé entre les deux bouts du programme.

Citation:

---

Envoyé par Charlemagne

Je réussis à lier mon programme avec ma DLL, mais son lancement m'annonce qu'il lui faut impérativement la DLL de STLport. Donc il y a dorénavant une dépendance dynamique (alors que la dépendance était auparavant statique avec les LIB)

---

Oui, les DLL ne sont pas linkées... Puisque c'est tout leur intérêt...
Pourquoi ne pas utiliser des libs statiques ? Il me semble que dans les options de projet d'une bibliothèque statique visual C++, tu as un onglet nommé Librerian qui te permet d'aggréger une autre bibliothèque statique avec la tienne. Il me semble que j'ai déjà eu des surprises avec cet onglet, mais je ne sais plus lesquelles, et c'était à un moment où j'avais pas eu le temps de prendre le temps de comprendre.

Citation:

---

Envoyé par Charlemagne

En fait il y a a qq part dans un '.h' de STLport une instruction pour importer la bonne librairie. (j'ai pas encore dénicher l'endroit dans le code. Vu que je connais pas l'instruction, c'est pas facile à trouver)

---

Regarde un truc genre #pragma comment (lib:...)

Citation:

---

Envoyé par Charlemagne

Ca me laisse penser qu'il existe bien une possibilité, pour faire en sorte que le code C++ sache si le compilo est en mode statique ou dynamique)

---

Souvent, le compilatuer définira des macros préprocesseur (genre DLL).

Il est tard, j'ai pas encore essayé tes propositions, mais ca devrait m'avancer sérieusement.

Citation:

---

Donc, au final, dans le programme, std::complex vaudra des choses différentes selon là où on se trouve ? C'est une violation de l'ODR, ce qui est un comportement indéfini. En pratique, pour ce genre de manip, il faut surtout éviter par dessus tout que des variables de tous ces types soient passé entre les deux bouts du programme.

---

Je n'avais pas pensé à ce problème éventuel. Ca devrait pas être un problème pour les complexes dont le code est normalement intégralement dans les '.h', à moins d'instanciations explicites dans la librairie STL. Mais la remarque est pertinente. Y'a surement quelques fonctions instanciées (je pense aux entrées-sorties), mais pour l'instant j'ai pas vu de doubles définitions lors de l'édition de lien avec le programme utilisateur.
Le problème sera peut-être plus flagrant avec ta proposition un peu plus loin d'aggréger des libs statiques.
Que faire si y'a des doublets lors de l'édition de lien?

Citation:

---

Pourquoi ne pas utiliser des libs statiques ? Il me semble que dans les options de projet d'une bibliothèque statique visual C++, tu as un onglet nommé Librerian qui te permet d'aggréger une autre bibliothèque statique avec la tienne. Il me semble que j'ai déjà eu des surprises avec cet onglet, mais je ne sais plus lesquelles, et c'était à un moment où j'avais pas eu le temps de prendre le temps de comprendre.

---

Ca aussi ça peut m'intéresser, si y'a pas de problème de doublets.
Je connais pas cette posibilité de fusionner des libs. Si ça marche, je l'adopte.
C'est l'option "additional dependencies" dans Liberian?

Citation:

---

Regarde un truc genre #pragma comment (lib:...)
Souvent, le compilatuer définira des macros préprocesseur (genre DLL).

---

Je vais tâcher de voir ça demain.

Mes essais ne sont pas concluants, et donc j'ai encore des questions.

1)
J'ai pas trouvé le moyen de fusionner/aggréger des libs statiques. J'ai bien essayé l'option 'additional dependencies' dans l'onglet Liberian, pour inclure la librairie statique de STLport. Mais lors de l'édition de lien du programme utilisateur, ma librairie impose encore la dépendance envers la lib statique de STLport.

2)
C'est bien "#pragma comment (lib: )" pour importer des libs dans le code source.
Et j'ai effectivement trouvé la macro _DLL, définie par Visual lorsque le code généré est en "Multithreaded DLL" (/MD, /MDd).
Mais cette macro ne permet pas de savoir si le compilo génère ou non une DLL. Car il est tout-à-fait possible de faire une librairie statique en MD !!!, comme il est possible de faire une librairie dynamique en MT/ML !!!
Je pense avoir une idée de ce qu'est la géneration single/muti threaded (ML/MT), mais je comprends donc plus à quoi sert le multithreaded DLL.

Pour ta question 2, c'est en fait à quel runtime on va lier ta bibliothèque. Ce runtime contient en gros la bibliothèque standard, et on peut l'avoir en version statique ou dynamique, en version monothread - plus rapide - ou multithread - quand on utilise les threads :aie: -

Citation:

---

Envoyé par Charlemagne

1)
J'ai pas trouvé le moyen de fusionner/aggréger des libs statiques. J'ai bien essayé l'option 'additional dependencies' dans l'onglet Liberian, pour inclure la librairie statique de STLport. Mais lors de l'édition de lien du programme utilisateur, ma librairie impose encore la dépendance envers la lib statique de STLport.

---

Désolé, je ne peux pas vraiment t'aider, puisque comme je l'ai dit, je n'ai jamais vraiment utilisé ce truc. Peut-être permet-il juste d'éviter à l'utilisateur de devoir spécifier dans son projet qu'il a besoin de l'autre bibliothèque, mais ne permet pas d'éviter qu'elle soit fournie ?

Le dernier conseil que je peux donner, c'est d'utiliser dumpbin.exe(http://msdn2.microsoft.com/fr-fr/library/756as972.aspx) pour deboguer les symboles présents dans une lib.