Discussion :

[Franck.H]

Je sais, question récurrente dans ce forum mais peut-être pas plus que ça aller hop j'me lance

Je sais que sous Windows on déclare/définit et appel les fonctions partagées comme ceci

Code :

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

__declspec(dllexport) int Fonction(void)

Est-ce exact ? Des précisions peut-être à ce niveau ? Je débute complètement dans le domaine des DLL Si c'est ok pour Windows passons aux Unixoïdes, y a-t-il des choses à savoir à ce sujet ? Un équivalent à __declspec(dllexport) ?

[Franck.H]

Ne connaissant pas la version Linux, j'ai fait une première ébauche de constante pour faciliter l'écriture, comme j'ai souvent vu dans ce genre de cas :

Code :

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

1
2
3
4
5
6
7
#ifndef DECLSPEC
#  if defined(GNUC)
#     define DECLSPEC
#  elif defined(MINGW)
#     define DECLSPEC __declspec(dllexport)
#  endif
#endif

[kwariz]

Bonjour,

L'approche windows et l'approche *nix diffèrent totalement sur ce point. En windows tout ce qui n'est pas déclaré comme étant visible de l'extérieur est caché, en unix tout ce qui n'est pas déclaré comme étant caché est visible de l'extérieur
Ensuite cela va aussi dépendre de ta chaîne de compilation, il y a en gros trois cas (je ne passe pas en revue les cas de cross compilation) :

1. compilateur microsoft, tu génères une DLL pour windows sous windows
2. gcc+binutils, tu génères un so pour linux sous linux
3. gcc+binutil, tu génères une DLL pour windows sous windows

Le cas 1 nécessite l'utilisation des __declspec avec comme arguments dllimport/dllexport, le cas 3 aussi mais avec la syntaxe gcc ; le cas 2 ne nécessiterait rien de particulier mais on peut utiliser les attributs de visibilité proposés par gcc pour avoir un comportement similaire.

L'approche usuelle pour gérer du code unique pour tous ces cas est de définir des macros API_PUBLIC et API_HIDDEN utilisées pour marquer les fonctions de ton API. Elles devront en plus avoir une définition différente lors de la construction de la bibliothèque et lors de son utilisation. Du coup il faudra définir une autre macro (BUILDING_MY_LIB) uniquement lors de la construction de la bibliothèque (pour pouvoir choisir en dllimport et dllexport).
Cela pourrait donner quelquechose comme :

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
#if defined defined _WIN32 || defined __CYGWIN__
        /* On est sous windows, reste à déterminer le compilateur utilisé */
#  if defined BUILDING_MY_LIB
        /* On construit la bibliothèque -> on va exporter les symboles*/
#    if defined _MSC_VER
        /* compilateur microsoft */
#      define API_PUBLIC __declspec(dllexport)
#      define API_HIDDEN
#    elif defined __GNUC__
        /* gcc sous windows = mingw/cygwin, mais aussi icc (je crois) */
#      define API_PUBLIC __attribute__((__dllexport__))
#      define API_HIDDEN
#    else
        /* autre compilateur : vaut mieux tout arrêter */
#      error "Unsupported compiler"
#    endif
 
#  else /* NOT BUILDING_MY_LIB */
        /* On utilise la bibliothèque : on importe les symboles */
#    if defined _MSC_VER
#      define API_PUBLIC __declspec(dllimport)
#      define API_HIDDEN
#    elif defined __GNUC__
#      define API_PUBLIC __attribute__((__dllimport__))
#      define API_HIDDEN
#    else
#      error "Unsupported compiler"
#    endif
 
#  endif /* BUILDING_MY_LIB */
 
 
#else /* NOT FOR WINDOWS */
 
#  define API_PUBLIC __attribute__(( __visibility__ ("default") ))
#  define API_HIDDEN __attribute__(( __visibility__ ("hidden") ))
 
#endif /* Platform selection */

Ensuite dans un header exporté tu pourras les utiliser ainsi :

Code :

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

1
2
3
4
5
 
#ifndef MONHEADER_H__
...
API_PUBLIC void ma_super_fonction(int, const char*);
...

Dans un header non exporté :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
#ifndef INTERNHEADER_H
#define  INTERNHEADER_H
 
#ifndef BUILDING_MY_LIB
#  error "Only for internal use"
#endif
 
API_HIDDEN void fonction_visible_en_interne();
API_PUBLIC void ma_super_fonction(int, const char*);

Et dans un source quelconque :

Code :

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

1
2
API_HIDDEN static void fonction_visible_de_nulle_part();
API_HIDDEN void fonction_visible_en_interne();

Voilà en gros la démarche usuelle utilisée

[Franck.H]

Code :

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

1
2
3
4
5
 
__attribute__
__dllexport__
__dllimport__
__visibility__

Ils sont définis quelque part je suppose dans les bibliothèques utilisées par le compilateur ou le système ?

Qu'entend-tu par header exporté ou non exporté ?

[kwariz]

Code :

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

1
2
3
4
5
 
__attribute__
__dllexport__
__dllimport__
__visibility__

Ils sont définis quelque part je suppose dans les bibliothèques utilisées par le compilateur ou le système ?

Qu'entend-tu par header exporté ou non exporté ?

Ce sont des extensions gcc, il faut peut-être faire attention à la version du gcc utilisé et des binutils ... disons que pour une distrib linux récentre (avec gcc 4 ou +) il n'y aura pas de problèmes.
Pour être un peu plus complet il faudrait remplacer la fin des defines par :

Code :

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

1
2
3
4
5
6
7
8
9
#else /* NOT FOR WINDOWS */
#  if __GNUC__ >= 4
#    define API_PUBLIC __attribute__(( __visibility__ ("default") ))
#    define API_HIDDEN __attribute__(( __visibility__ ("hidden") ))
#  else /* __GNU_C__ < 4 */
#    define API_PUBLIC
#    define API_HIDDEN
#  endif /* __GNUC__ >= 4 */
#endif /* Platform selection */

C'est vrai que mes termes ne sont pas adéquats
Disons que ça dépend de l'architecture de ton environnement de construction. J'aurais du parler de headers distribués et de headers internes.
L'utilisateur final de ta bibliothèque n'aura que la bibliothèque, celui qui désire développer avec ta bibliothèque aura la bibliothèque et les headers qui décrivent l'api (donc des headers qui ne devront pas utiliser API_HIDDEN a priori) -> headers distribués incorrectement appelés exportés.
Mais tu peux avoir besoin lors de la construction de ta bibliothèque d'autres headers qui ne seront jamais distribués qui eux pourront comporter des API_HIDDEN -> headers internes incorrectement appelés non exportés.

[Franck.H]

Ok c'est plus clair maintenant pour ton exemple que je vais reprendre si tu le permet et surtout pour tes explications

[kwariz]

Ok c'est plus clair maintenant pour ton exemple que je vais reprendre si tu le permet et surtout pour tes explications

Bah oui C'est fait pour
Bon courage !