Discussion :

[elraton]

Bonjour,

J'ai créer une librairie qui utilise les librairie tinyxml et libjpeg.
Ayant seulement envie d'intégrer et de distribué ma librairie j'ai decidé de faire la chose suivant:

Je compile tinyxml en static
Je compile libjpeg en static

Puis je compile malib en dynamic en incluant les versions deux autres librairies:

Sous MinGW les commandes pour linker donnent:

C:\MinGW\bin\ar.exe cr ..\lib\libtinyxml.a tinystr.cpp.obj tinyxml.cpp.obj \tinyxmlerror.cpp.obj tinyxmlparser.cpp.obj
C:\MinGW\bin\ranlib.exe ..\lib\libtinyxml.a

meme chose pour jpeg

C:\MinGW\bin\gcc.exe -shared -o bin\malib.dll -Wl,--out-implib,lib\malib.dll.a -Wl,--major-image-version,1,--minor-image-version,0 obj1.o obj2.o obj3.o 3rdparty\lib\liblibjpeg.a 3rdparty\lib\libtinyxml.a

Au final quand je créer mon programme je doit utiliser:

C:\MinGW\bin\g++.exe -Wall main.cpp.obj -o bin\AdVisOr.exe -Wl,--out-implib,lib\libAdVisOr.dll.a -Wl,--major-image-version,0,--minor-image-version,0 lib\malib.dll.a 3rdparty\lib\liblibjpeg.a 3rdparty\lib\libtinyxml.a

alors que j'aimerais ne pas avoir a inclure 3rdparty\lib\liblibjpeg.a 3rdparty\lib\libtinyxml.a, car du coup cela me désavantage de devoir inclure de nouveaux les librairies static.

Je ne trouve pas grand chose sur le Web et j'utilise Cmake pour la compilation.

[Mac LAK]

Tout simplement parce que tu as exporté des éléments de tes deux librairies statiques dans l'interface de ta librairie dynamique... Du coup, un programme utilisant la DLL doit linker aussi avec les librairies statiques pour réussir à trouver tous les symboles.

Typiquement, c'est mettre dans un entête de classe un attribut qui est défini dans une librairie statique (=> demande à faire une classe intermédiaire et/ou du cast sauvage avec void*) et/ou du code (toujours dans le .H) utilisant directement les fonctions de la librairie statique (=> les mettre dans le .CPP).

Tu as aussi la farce quand ton compilateur exporte par défaut TOUTES les fonctions de la DLL, au lieu de se limiter à celles définies explicitement. Là, faut voir la doc du compilo pour savoir comment empêcher l'exportation d'un symbole dans une DLL.

Il te faut :

• Vérifier ce que ta DLL exporte actuellement (via Dependancy Walker), afin de repérer l'élément posant problème.
• Repenser ton interface DLL de façon à n'exposer QUE tes propres fonctions / classes, en MASQUANT l'implémentation / utilisation des éléments des deux librairies statiques.
  Ceci implique un remaniement lourd de tes entêtes, l'utilisation de classes plus génériques qui seront les seules réellement exportées, l'utilisation de "void*" à outrance avec casts internes pour masquer le type réel de l'implémentation, ...

[elraton]

Oky, merci

donc si j'utilise des fonctions de tinyxml dans ma libraires et dans mon programmes j'ai intérêt a l'utiliser en tant que shared, ou directement inclure le code dans malib.dll.

Par contre si j'arrive a cacher libjpeg c'est mieux de le compiler en statique et de le cacher dans malib.

c'est bien ca ?

[Mac LAK]

Je vais prendre un exemple, ce sera plus clair...

Voici par exemple un bout du code d'une librairie statique :

Code Private.h :

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

1
2
3
4
5
6
7
8
#include <........>
 
// Structure de contrôle utilisée partout dans la librairie pour toutes les fonctions, comme l'est "FILE*" pour l'accès aux fichiers.
typedef struct {
 ....
 ....
 ....
} private_handle ;

Ce code est censé, à priori, rester "planqué" et non visible depuis ta DLL.

Or, imaginons que tu as un entête public de ta DLL construit ainsi :

Code Public.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
#include "Private.h" // pour "private_handle"

class Bidule {

  // Ouverture d'une ressource. La valeur de retour est passé à toutes les méthodes de la classe, MAIS L'UTILISATEUR NE LA MANIPULE JAMAIS DIRECTEMENT.
  // La méthode met à jour l'attribut m_PrivateHandle de la classe.
  bool Open ( .... ) ;

  // Travail effectif.
  int Process ( ..... ) ;

  // Fermeture.
  bool Close ( void ) ;

private:
  private_handle* m_PrivateHandle ;

} ;

Problème : private_handle fait partie de la librairie statique, devrait être privé, et est utilisé par une classe publique via un attribut... Du coup, pour pouvoir compiler, tu dois inclure l'entête de la librairie statique, qui va bien entendu forcer un link de cette librairie statique au sein de ton exécutable, alors que tu croyais n'utiliser que ta DLL !!

Pour corriger, tu devras faire ainsi :

Code Public.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
// On supprime le #include public vers la librairie statique.

class Bidule {

  // Ouverture d'une ressource. La valeur de retour est passé à toutes les méthodes de la classe, MAIS L'UTILISATEUR NE LA MANIPULE JAMAIS DIRECTEMENT.
  // La méthode met à jour l'attribut m_PrivateHandle de la classe.
  bool Open ( .... ) ;

  // Travail effectif.
  int Process ( ..... ) ;

  // Fermeture.
  bool Close ( void ) ;

private:
  void* m_MaskedPrivateHandle ;  // Passage en void*

} ;

Code Public.cpp :

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
#include "Public.h"
#include "Private.h" // pour "private_handle", il passe donc dans le CPP.
 
bool Bidule::Open ( .... ) {
 
  private_handle* m_PrivateHandle ;
 
  // Reste de la fonction.
 
  // Affectation de l'attribut avec cast.
  m_MaskedPrivateHandle = static_cast<void*>(m_PrivateHandle) ;
}
 
int Bidule::Process ( ..... ) {
 
  // Via un cast, on récupère le handle "normalement", avec l'ancien nom d'attribut pour éviter d'avoir à modifier inutilement le code déjà écrit.
  private_handle* m_PrivateHandle = static_cast<private_handle*>(m_MaskedPrivateHandle) ;
 
  // Corps de la fonction, inchangé désormais.
}
 
...

Ainsi, même si la DLL continue d'utiliser la librairie statique, cela n'est pas visible de l'extérieur, et aucun entête de la librairie statique n'est requis. Du coup, ton exécutable n'aura plus besoin d'être linké avec la librairie statique en question...


Tu vois mieux de quoi je veux parler ?

[elraton]

Oky, parfait ...
merci pour l'aide

[nicroman]

Je pense que Mac y va un peu fort....

Si ton entete est:

Code :

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

1
2
3
4
5
6
7
 
struct mallibprivatestruct;
class DLL_EXPORT DeMaLib
{
    private:
      malibprivatestruct*   m_pStruct;
};

Personne (utilisateur) n'a besoin d'avoir la définition de malibprivatestruct, juste celle d'un pointeur !