Discussion :

[Charlemagne]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Matthieu Brucher]

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

[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?

[Médinoc]

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

[Matthieu Brucher]

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++.

[Charlemagne]

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.

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.

[Matthieu Brucher]

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

[Charlemagne]

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?

[Médinoc]

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...

[Charlemagne]

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?

[Laurent Gomila]

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.

[Matthieu Brucher]

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.

[Charlemagne]

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

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?

[Laurent Gomila]

Mais ça marcherait avec une DLL?

Oui.

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).

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

[Médinoc]

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...)

[Charlemagne]

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...

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

[Médinoc]

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 MaDll.h :

Sélectionner tout - Visualiser dans une fenêtre à part

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é...

[Charlemagne]

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?

[Médinoc]

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...

[Charlemagne]

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