Discussion :

[Jeromnimo]

Bonjour à toutes et tous,

je reviens vers vous pour la suite de mes aventures.

Suite aux conseils donné dans mon précédent post (http://www.developpez.net/forums/d88.../creation-dll/), j'ai pu créer mes libs et tester le fonctionnement pour une première application.
Voici donc l'arcitecture :
lib1 -> lib statique n'utilisant pas Qt
lib2 -> lib dynamique utilisant QtCore + lib1
lib3 -> lib dynamique utilisant QtCore + QtXml + lib2

app1 -> application utilisant QtCore + QtXml + QtNetwork + lib1 + lib2 +lib3

A la compilation :
lib1 -> ok, elle est en TEMPLATE=lib et CONFIG=staticlib, j'obtiens donc un lib1.a
lib2 -> ok aussi, elle est en en TEMPLATE=lib et CONFIG=dll, j'obtiens donc lib2.a et 2.dll
lib3 -> idem lib2

Ensuite, au niveau de l'application, j'ai rajouté les chemin des headers dans le .pro, donc compilation ok, ainsi que :
LIBS+= -Lchemin/lib1/ -l1
LIBS+= -Lchemin/lib2/ -l2
LIBS+= -Lchemin/lib3/ -l3

Et là, au link, je me fais jeter, avec des "undefined reference to..." concernant mes 3 lib persos (sachant que app1 est en plus linké avec Irrlicht et qwt et que pour ces deux libs là, aucun problème...)

2 questions qui découlent de ceci :
- lorsque j'écris LIBS+= -Lchemin/lib2/ -l2 et que lib2.a et 2.dll se trouvent dans chemin/lib2/, laquelle des deux est prise en compte ? la statique ou la dynamique ??
- avez vous une idée d'où peut venir mon problème de link ??

Merci d'avance

[johnlamericain]

2 questions qui découlent de ceci :
- lorsque j'écris LIBS+= -Lchemin/lib2/ -l2 et que lib2.a et 2.dll se trouvent dans chemin/lib2/, laquelle des deux est prise en compte ? la statique ou la dynamique ??
- avez vous une idée d'où peut venir mon problème de link ??

Je pense qu'il y a erreur de compréhension dans la notion de lib dynamique (si je ne m'abuse).

Une librairie dite "dynamique" n'a pas de lien fort avec l'exécutable, elle est chargée à partir d'un loader (http://qt.developpez.com/doc/latest/qlibrary.html). Qu'elle soit présente ou non, je dirais que ton application doit fonctionner et éventuellement retourner un message du genre "Impossible de charger la dll".
Elle n'est donc pas linker dans les options de configuration de Qt.

A l'inverse des librairies statiques qui elles sont embarquées dans l'application directement et ont donc un lien fort avec. Pour moi ton problème vient bien des librairies statiques.

Perso j'ai toujours ajouté les noms des libs directement car j'ai jamais réussi à faire marcher la commande -L ...

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
win32 { 
    CONFIG( debug, debug|release ){:
        #Debug
        LIBS += ../../Tracer/Src/debug/Tracerd.lib
    } else {
        #Release
        LIBS += ../../Tracer/Src/release/Tracer.lib
    }
} else:macx {
    CONFIG( debug, debug|release ) { 
        # Debug
        LIBS += ../../Tracer/Src/debug/libTracerd.a
    }
    else { 
        # Release
        LIBS += ../../Tracer/Src/release/libTracer.a
    }

Je ne sais pas si c'est très propre mais ça marche

[Jeromnimo]

Tout d'abord, merci de la réponse
Oui effectivement, je connais la différence entre une lib dynamique et statique, et clairement, la librairie dynamique est chargée à l'exécution
Mais par contre, il faut bien la spécifier au moment du link, pour "prévenir" l'exécutable qu'il va devoir la charger à l'exécution

[johnlamericain]

Tout d'abord, merci de la réponse
Oui effectivement, je connais la différence entre une lib dynamique et statique, et clairement, la librairie dynamique est chargée à l'exécution
Mais par contre, il faut bien la spécifier au moment du link, pour "prévenir" l'exécutable qu'il va devoir la charger à l'exécution

Hummm je me trompe peut être mais j'en suis pas persuader.

La notion de librairie dynamique pour moi est très utile dans le cas ou l'on veut par exemple créer une application à base de plugin et qu'un ensemble de plugin peut être ajouter à l'application sans avoir à recompiler l'application de base.
Il n'y a donc pas de link entre l'appli et la lib dynamique sinon on serait obliger de recompiler systématiquement le programme.

Par contre il faut que l'entête et les signatures des fonctions utilisés soit connus par l'application, ce qui je ne croit pas correspond à un link de la librairie dans le .pro (pour le cas de Qt).

Merci de me corriger, la vérité m'intéresse

[dourouc05]

Je ne sais pas si c'est très propre mais ça marche

J'aurais tendance à dire : non, pas du tout, mais alors là pas du tout. En effet, tu ne prévois pas les cas où VC/Borland n'est pas le compilo sous Windows, et où GCC ne l'est pas sous OSX (bon, pour ce deuxième cas, je ne connais pas d'autre compilo C++ pour OSX...).

Une librairie dite "dynamique" n'a pas de lien fort avec l'exécutable

Renomme QtGui4.dll en john.dll. Ça fonctionnera ? Non, pas vraiment, sauf si tu précises dans l'exécutable à l'OS qu'il doit charger cette autre DLL.

Une librairie statique n'a pas de lien avec l'application : elle est DANS l'application. La dynamique est justement en dehors. Petite comparaison : tu as un téléphone. Il est lié dynamiquement à toi : tu sais quelle forme il a et ce que tu peux faire avec. S'il était lié staitquqmene,t, tu aurais un téléphone greffé dans la tête, et tu pourrais communiquer directement avec lui sans risque qu'un tiers te le pique. Maintenant, si quelqu'un change la forme de ton téléphone dynamique sans t'en prévenir, et que tu n'as pas grand chose en tête, tu vas te demander ce que tu dois utiliser pour téléphoner, vu que tu n'as plus de téléphone. En gros, la situation. (Bon, d'accord, en très gros).

Une lib chargée avec QLibrary sera plutôt considérée comme un plug-in : ton app n'en a pas de besoin vital. Donc, pas d'obligation de la charger dès le lancement de l'app, tu ne la charges qu'en cas de nécessité, et ton app continue de fonctionner sans elle. La forme du plug-in est quand^même une lib dynamique, vu qu'elle est hors d'un exécutable, et qu'elle utilise la même représentation qu'une DLL (sinon, bonjour les dégâts au chargement : comment fait-on ?).

Par contre il faut que l'entête et les signatures des fonctions utilisés soit connus par l'application, ce qui je ne croit pas correspond à un link de la librairie dans le .pro (pour le cas de Qt).

Pour un plug-in, il ne me semble pas que ce soit nécessaire, au contraire de la lib liée dynamiquement. Le plug-in offre ses services, QLibrary peut les lire. La lib liée dynamiquement, on connaît ses services. Dans les deux cas, on ne sait pas comment ça fonctionne, et on s'en fout.

Quand tu linkes dans le pro, tu force le link dynamique, donc avec le nom de la dll dans l'exe, puis l'os charge la dll avec l'app, idem pour les plug-ins que tu mets dedasn (car nécessaires à la survie, le linker les lie pour être sûr que l'app se cahrge avec eux).



En résumé :
lib liée statiquement => tout dans l'exécutable
lib liéé dynamiquement => contenu chargé à l'exécution, l'app en a besoin, elle en connaît toutes les fonctions/méthodes
lib dynamique non liée == plug-in => on charge les fonctions (pour les méthodes, c'est plus risqué, voir le système de plug-ins de Qt, absolument nécessaire en ce cas ; sinon, on est limité aux appels de fonction C-style) à l'exécution, on n'en sait rien avant, si ce n'est qu'on peut en avoir.
DLL => ce avec quoi l'app est liée dynamiquement, ce qui sert de plug-ins.

Les plug-ins sont donc très semblables aux libs liées dynamiquement, la seule différence est que le nom des dll est inscrit en dur dans l'exe et qu'elels sont chargées dès le chargement de l'app ; au contraire, les plug-ins sont chargés après le lancement, l'utilisateur peut en fixer le nom à sa guise, ou bien le développeur, ou bien un ficheir de conf, ou tout ce qu'on veut, ce n'est pas écrit en dur.

Sans être même sûr d'apporter beaucoup de réponses...

[johnlamericain]

Merci dourouc pour ces précisions et ces corrections.

La prochaine fois j'attendrais que quelqu'un de plus compétent que moi dans le domaine réponde...

[Jeromnimo]

Merci pour toutes les précisions (qui confirment mes pensées )
Par contre je n'arrive toujours pas à linker
J'ai tenté hier avec une "appli" très simple (construction de 2 objets et appel d'une méthode de ma lib1, et la ça link.. je n'arrive pas à comprendre d'où vient le problème

[Jeromnimo]

Je continue ma petite vie...
En fait ça ne link que si aucune lib QT n'est linkée en plus...
en gros

Code :

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

1
2
 
g++ ... -llib1

ca passe
mais

Code :

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

1
2
 
g++ ... -lib1 -lQtCore

ca ne compile plus...


Je continue de creuser, j'espere trouver d'ou vient cette connerie (qui j'en suis sûr, c'est vraiment pas grand chose...)

[Jeromnimo]

Bon ben j'ai finalement trouvé... en fait, dans le makefile généré, la lib "mingw32" est incluse AVANT mes libs...

En inversant à la main ces link, ca roule... reste à trouver comment "inverser" cela proprement au moment de la génération du makefile...

Je retourne me plonger dans mon fichier .pro

[Jeromnimo]

C'était finalement une somme de conneries cumulées durant mes 12000 essais... (et le message précédent s'explique par le fait que j'avais laissé trainer une de mes dll - dans une version précédente -) dans le répertoire des lib de QT... honte à moi

Merci en tout cas à tous ceux qui ont pris le temps de lire et répondre