Discussion :

[Jeromnimo]

Bonjour à toutes et tous,

ayant rejoint une équipe où un certain nombre de développements ont été réalisés, j'ai en charge de diviser le code en plusieurs bibliothèques réexploitables.
Le découpage a été pensé, ça c'est OK, mais la je galère un peu avec Qt pour obtenir une dll (certaines bibliothèques sont vouées à être statiques - notamment car elles vont être linkées avec des applis temps réel -, et d'autres dynamiques, car sans contraintes particulières).
J'ai donc deux grandes questions :
1) si je génère une bibliothèque statique libA.a, et qu'ensuite une bibliothèque B l'utilise, est-il possible que B soit dynamique ?

2) impossible de générer seulement une bibliothèque avec Qt, si je mets :

Code :

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

1
2
3
4
5
 
TEMPLATE = lib
CONFIG += staticlib
TARGET = A
....

dans libA.pro, j'obtiens bien libA.a après un qmake et g++

Par contre, lorsque je fais :

Code :

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

1
2
3
4
5
 
TEMPLATE = lib
CONFIG += dll
TARGET = A
....

dans ce cas là la compilation me donne libA.a et A.dll ??? (alors que je m'attendais à avoir libA.dll seulement...)

Quelqu'un aurait une explication ???

Merci d'avance pour vos réponses.

[johnlamericain]

1) si je génère une bibliothèque statique libA.a, et qu'ensuite une bibliothèque B l'utilise, est-il possible que B soit dynamique ?

Bien sur, et heureusement

2) impossible de générer seulement une bibliothèque avec Qt, si je mets :

Code :

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

1
2
3
4
5
 
TEMPLATE = lib
CONFIG += staticlib
TARGET = A
....

dans libA.pro, j'obtiens bien libA.a après un qmake et g++

Par contre, lorsque je fais :

Code :

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

1
2
3
4
5
 
TEMPLATE = lib
CONFIG += dll
TARGET = A
....

dans ce cas là la compilation me donne libA.a et A.dll ??? (alors que je m'attendais à avoir libA.dll seulement...)

Quelqu'un aurait une explication ???

De mémoire, en dynamique, Qt génère à la fois le .a et le .dll (dans ton cas) mais ce n'est pas gênant, tu peux utiliser le fichier qui t'intéresse uniquement, à savoir le .dll. Il n'y a pas de lien fort entre le .a et le .dll.

[dourouc05]

De mémoire, en dynamique, Qt génère à la fois le .a et le .dll (dans ton cas) mais ce n'est pas gênant, tu peux utiliser le fichier qui t'intéresse uniquement, à savoir le .dll. Il n'y a pas de lien fort entre le .a et le .dll.

Qt utilise un compilateur. Tu lui demandes de faire une lib, donc un fichier DLL. Or, le compilateur ne peut pas utiliser firectement une DLL (notamment en mode débug, lil y stocke pas mal d'infos inutiles dans le binaire de la DLL). Donc, il crée un fichier qui lui permet de savoir ce qu'il veut savoir sur la DLL. Notamment, les fonctions disponibles à l'import, qui peuvent être définies dans un .def. Cependant, il ne les aime pas trop, car il ne peut pas y stocker exactement tout ce dont il a besoin. Il a donc recours aux fichiers .lib / .a pour stocker les fonctions disponibles, le fichier dans lequel elles sont disponibles, et bien d'autres.

En gros, le fichier .a dit au compilo ce qu'il peut trouver dans le .dll, et ne regardera même pas le .dll. Il ne sera chargé qu'à l'exécution, pas avant (on n'a pas besoin du code binaire avant).

Dans le cas d'une lib statique, les deux fichiers sont combinés en un seul, le .lib / .a contenant tout : la liste des méthodes et leur implémentation.

[Jeromnimo]

Merci beaucoup de toutes vos réponses, je comprends mieux maintenant
Par contre c'est quand même bizarre la gestion du nom du .a et du .dll généré (l'un se voit préfixé de lib et l'autre non...)
Je vais vérifier si le comportement est le même sous linux.

Merci encore.

[johnlamericain]

Merci beaucoup de toutes vos réponses, je comprends mieux maintenant
Par contre c'est quand même bizarre la gestion du nom du .a et du .dll généré (l'un se voit préfixé de lib et l'autre non...)
Je vais vérifier si le comportement est le même sous linux.

Merci encore.

Non, c'est tout à fait normal, c'est la convention de nommage.

[dourouc05]

Par contre c'est quand même bizarre la gestion du nom du .a et du .dll généré (l'un se voit préfixé de lib et l'autre non...)
Je vais vérifier si le comportement est le même sous linux.

Ils en ont décidé ainsi, tu ne les feras pas changer d'avis. Le comportement sera strictement identique tant que tu utiliseras GCC et ce qui va avec. Quand tu changeras de compilateur, alors tu verras la magie des conventions changer : pour VS, par exemple, rien du tout comme préfixe. Le fichier .lib (équivalent .a) a donc exactement le même nom que la DLL, sauf exceptions (tu peux changer le nom du .lib sans problème, pas de la DLL).

Fais attention avec GCC : même si le ficheir est préfixé de lib, il ne faut pas le mettre quand tu le passes au compilateur. C'est toujours un -ltoto pour lier contre libtoto.a (et toto.so à l'exécution).