Discussion :

[madmox]

Bonjour,

Je cherche à créer une bibliothèque C++ (statique ou dynamique, je n'ai pas décidé) qui encapsule l'API sockets de la plateforme. C'est à dire WinSock pour windows, posix sockets pour linux.

Je commence par windows, et je dois donc utiliser la bibliothèque WS2_32.lib (qui utilise elle même une dll je crois). Mais voilà, j'aimerais qu'un utilisateur de ma bibliothèque n'ait à se linker qu'avec la mienne !

Comment procéder dans les 2 cas (statique et dynamique), et est-ce possible ?

Note : Jusque là j'arrive à créer une bibliothèque statique, mais tout exécutable qui l'utilise doit aussi se linker à WS2_32.lib (et après ma bibliothèque).

Note 2 : Pas trop envie d'utiliser des astuces du genre #pragma comment(lib, "WS2_32.lib") dans le code des headers, car trop spécifique au compilateur VC++.

[Laurent Gomila]

Si tu crées une bibliothèque dynamique tu n'auras aucun problème.

Pour une bibliothèque statique, là ça dépend fortement de ton environnement de développement.

Avec Visual C++, il suffit d'ajouter ws2_32.lib dans les "input libraries" et il sera lié automatiquement dans tout programme utilisant ta bibliothèque.

Avec gcc et ses dérivés c'est déjà plus embêtant, il faut faire tourner une commande externe qui extrait les .o de libws2_32 et les ajoute à ta bibliothèque (un bibliothèque .a n'est qu'une bête archive de fichiers .o). Sous Windows cela signifie qu'il te faut un environnement Linux (msys, cygwin).
Je détaille cette manipulation à la fin de ce tutoriel :
http://www.sfml-dev.org/tutorials/1.3/start-cb-fr.php

[Mat007]

Salut,

A moins bien sûr que ça soit à but pédagogique, ça n'a pas tellement d'intérêt de refaire ce qui existe déjà, je pense notamment à Boost.Asio.

Sinon une petite mise en garde sur l'inclusion de bibliothèque statique à l'intérieur d'une autre : c'est très dangereux !
Avec ar notamment, deux fichiers .o qui portent le même nom vont entrer en concurrence et l'un va écraser l'autre, et ce presque silencieusement...
Et puis si l'utilisateur final veut aussi par ailleurs lier avec une bibliothèque sournoisement déjà incluse dans une autre mais pas avec la même version exactement, ça va lui poser problème sachant qu'en général c'est encore une fois effectué silencieusement.

MAT.

[madmox]

Merci de vos réponse, c'est très intéressant. la meilleure solution serait donc de créer une bibliothèque dynamique a priori...

Je n'ai aucune expérience en la matière, j'ai regardé quelques cours, mais je ne vois pas encore comment gérer la dépendance à une bibliothèque statique pour une dll !

Disons que je crée ma libSockets.dll, mais qu'elle dépend de WS2_32.lib. Comment je répercute ça dans le code/ou plutôt les options de compilation ? J'ai juste besoin de compiler en liant à la bibliothèque statique ? L'utilisateur n'aura vraiment besoin de rien ajouter d'autre que ma bibliothèque ?

Pour l'aspect refaire ce qui existe déjà, je connais boost.asio qui est très performant mais c'est effectivement dans un objectif pédagogique que j'essaie de reproduire ce modèle avec des bibliothèques compilées. Parce que justement je maîtrise beaucoup mieux la programmation C/C++ que la compilation C/C++...

Edit: Autre question : la manipulation d'intégration d'une bibliothèque externe dans une autre est effectuable avec cygwin ou msys. Mais est-elle faisable pour des bibliothèques Windows à partir de linux ? En d'autre termes, les archives générées par ar sous linux sont-elles utilisables sous Windows si le code est compilé pour Windows ? Ça m'éviterait d'installer cygwin ou msys étant donné que j'ai un dual boot linux/windows.

[madmox]

Autres questions :

Le préfixe __declspec (dllexport) est-il réellement important dans les sources et headers du projet dll ?
Le préfixe __declspec (dllimport) est-il réellement important dans les headers du projet utilisant la dll ?
Ces préfixes doivent être utilisés dans quels cas (fonctions ? classes ?) ?

Après quelques tests ça a l'air de fonctionner sans le préfixe, je me demande à quoi il sert donc...

[Klaim]

Oui ils sont important : cela permet au compilateur (VC en l'occurence) de savoir quels symboles de la dll sont à exporter, et quels symboles utilisés par l'application qui utilise la dll sont à importer.

Donc, tu dois faire en sorte que dans tes headers les fonctions et méthodes qui sont dans définis dans ta dll mais dont l'application cliente n'aura que la déclaration soient indiqués comme __declspec (dllexport) pour le code source de la dll, et __declspec (dllimport) pour le code source de l'application client.

Tu dois l'indiquer pour les fonctions et méthodes, mais tu peux aussi indiquer que les méthodes de toute une classe sont dllexport/dllimport, en mettant ce mot après class dans la déclaration de ta classe.

Habituellement on utilise des macros qui déclarent l'un ou l'autre selon quel code source va être compilé.


Par contre si ton code est totalement contenu dans un header (par exemple si c'est une lib totalement templatée) alors tu ne dois pas les utiliser puisque le code sera généré à la compilation de l'application cliente et non dans la dll (sauf si elle en utilise mais ce sera local a la dll).

Attention toutefois, ce specifier n'est valide qu'avec VC (donc sous windows). Il me semble que gcc exporte tous les symboles par défaut, il faut donc faire la démarche inverse et spécifier ce qui ne devrait pas être exposé publiquement (principalement pour gagner en perfs à la compilation). Et de toutes façons le specifier est différent.