Discussion :

[Gourbish]

Salut à tous.

J'ai une petite question à vous poser, et un dessin plutôt que des phrases sera bien plus explicites.

A, B, et Z sont des petites librairies que j'ai créées.

A est une librairie qui utilise la librairie Z.
B est une librairie qui utilise la librairie Z.

Le programme final a besoin des deux librairies A et B.

Lors de la compilation j'ai une floppée de warnings qui m'expliquent que la librairie Z est définie 2 fois et que la seconde fois est ignorée (warning LNK4006 dans Visual Studio). Le programme fonctionne, mais il y a un warning pour chaque fonction présente dans Z.

Je voudrais donc savoir comment éviter tous ces warnings (sans les ignorer) pour avoir un programme plus propre. Je suppose qu'il y a quelque chose d'un peu brutal dans mon prog ou mes libs pour avoir tous ces warnings.

Merci d'avance.

Gourbish.

PS : on ne prend jamais le temps, mais... FELICITATIONS ET MERCI aux auteurs du site ainsi qu'à ceux qui l'enrichissent jour après jour, heure après heure que cela soit sur le forum ou sur les tutos ou autres. Longue vie à Developpez.com !!!

[Mac LAK]

A priori, tes librairies A, B et Z sont des librairies statiques. Dans un tel cas de figure, ce n'est JAMAIS la librairie A qui doit linker la librairie Z, mais le PROGRAMME utilisant la librairie A qui doit savoir que la librairie Z est également à inclure dans le link.

Côté Visual, cela veut dire qu'il te faut décocher la librairie Z dans les dépendances des librairies A et B, et l'ajouter à ton programme principal.


Ce cas arrive fréquemment si tu as inclus ta librairie Z via un #pragma comment(lib,"....") non protégé, dans les entêtes publics des librairies A et B.

[Gourbish]

Oui en effet ce sont des librairies statiques, j'avais oublié de préciser.
Mais si la librairie A a besoin de Z pour fonctionner, il faut bien qu'elle soit dans ses dépendances. Si A a besoin de certaines fonctions de Z, alors A va dépendre de Z. Je ne me trompes pas jusque là. Donc pourquoi m'expliques-tu que A ne doit JAMAIS linker Z ?

Sinon, pour ce qui est du "#pragma comment(lib,"....")", je n'ai rien de cela. Pour utiliser une librairie, j'ajoute le .lib dans les dépendances du projet, j'inclus le .h nécessaire dans le code, et roule ma poule. J'ai appris comme cela par moi même donc je ne sais pas trop à quoi correspond le #pragma comment(lib,"...."), et encore moins comment le protéger.

[Mac LAK]

Mais si la librairie A a besoin de Z pour fonctionner, il faut bien qu'elle soit dans ses dépendances.

Non, pas en statique. Tu as besoin bien entendu des chemins #include de Z dans ton projet A, mais pas du .LIB.

Si A a besoin de certaines fonctions de Z, alors A va dépendre de Z. Je ne me trompes pas jusque là. Donc pourquoi m'expliques-tu que A ne doit JAMAIS linker Z ?

Parce qu'il n'y a AUCUNE édition de lien avec une librairie statique... Tu peux vérifier dans tes options de projet A, B et Z, d'ailleurs : la section n'existe pas !

Sinon, pour ce qui est du "#pragma comment(lib,"....")", je n'ai rien de cela. Pour utiliser une librairie, j'ajoute le .lib dans les dépendances du projet, j'inclus le .h nécessaire dans le code, et roule ma poule. J'ai appris comme cela par moi même donc je ne sais pas trop à quoi correspond le #pragma comment(lib,"...."), et encore moins comment le protéger.

C'est pour ça que tu as un doublon sur Z : le rajout du .LIB dans le projet A ET dans le projet B rajoutes deux fois la librairie, tout simplement. Ce que tu fais ne serait valable que dans le cas de DLL (qui ont une phase d'édition de liens), et bien sûr d'exécutables (pareil).

Le #pragma permet d'indiquer à Visual qu'il doit linker le .LIB "tartempion" dès l'inclusion d'un header particulier. Cela évite d'avoir à rajouter manuellement le nom de la librairie dans les settings du projet, ou d'ajouter directement le fichier dans l'arborescence de fichiers du projet. C'est ce que l'on appelle un link automatique, c'est beaucoup utilisé pour les entêtes standards de Windows par exemple.
On protège ça en mettant le #pragma dans l'entête "racine" de la librairie (=celui utilisé par tout le monde, typiquement celui qui définit les déclarations d'importation/exportation pour une DLL par exemple). L'entête doit bien entendu être protégé contre les inclusions multiples (#ifdef / #define / #endif), et il est souhaitable d'ajouter un #pragma once juste avant le #pragma d'inclusion pour éviter par toutes les manières possibles un double lien du .LIB.

[Gourbish]

Bien bien bien tout ça...
Merci pour toutes ces explications.

Le soucis est donc résolu en suivant tes instructions, et je me coucherai moins couillon ce soir ! :-)


Pour le moment, j'ai donc résolu ça ainsi :
A dépend de Z.
Donc A contient des #include provenant de Z, et c'est tout.

Le prog final, lui, dépendant de A, va contenir :
- des fonctions provenant de A => dans ses dépendances, j'ai mis A.lib
- des fonctions provenant de Z => dans ses dépendances, j'ai mis Z.lib
Tout ceci étant fait dans les réglages du projet visual.
Cela fonctionne impec'.


Maintenant, dis moi si je me trompes, si je désire utiliser les #pragma :
- soit je fais des #pragma pour A et pour Z dans mon prog
- soit je fais un #pragma pour A dans prog et un #pragma pour Z dans la lib A

C'est cela ? Ainsi, le 2ème cas permettrait d'éviter de savoir qu'il existe une lib Z qu'il faut linker lorsque l'on linke déjà A.

[Mac LAK]

Maintenant, dis moi si je me trompes, si je désire utiliser les #pragma :
- soit je fais des #pragma pour A et pour Z dans mon prog
- soit je fais un #pragma pour A dans prog et un #pragma pour Z dans la lib A

C'est cela ? Ainsi, le 2ème cas permettrait d'éviter de savoir qu'il existe une lib Z qu'il faut linker lorsque l'on linke déjà A.

C'est bien cela, sauf qu'en général, chaque librairie définit son propre link.

Donc, dans un entête incontournable de la librairie Z, tu vas ajouter un #pragma comment(lib,"libZ") (tu noteras l'absence de l'extension .lib), précédé d'un #pragma once par sécurité.
S'il est possible d'inclure plusieurs entêtes de Z de façon indépendante (ex : librairie de plusieurs modules totalement indépendants), alors il te faudra ajouter le #pragma dans chaque entête "racine".

Tu fais ensuite la même chose pour la librairie A : ses entêtes indiquent le #pragma pour elle-même. Tu ne t'occupes pas de la librairie Z, sauf si elle n'est pas de toi bien sûr et que tu veux, justement, régler une dépendance manquante.
Dans ce dernier cas, les entêtes de A vont également inclure la librairie Z, de façon à rendre l'intégralité du processus de link automatique. C'est ce qu'il faut utiliser par exemple lorsque tu encapsules une librairie tierce.

Enfin, dans le programme principal, tu ne t'occupes de rien d'autre que de renseigner, éventuellement, les chemins d'accès aux librairies. Tu n'as pas à te préoccuper du nom de la librairie, juste du répertoire où elle est stockée, exactement comme un fichier d'inclusion.

Tu peux également linker automatiquement les versions Debug et Release, avec un code de ce genre :

Code :

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

1
2
3
4
5
6
7
8
9
#pragma once
#pragma message("Autolink : MyLib")
#ifndef _DEBUG
	#pragma comment(lib,"mylib")
	#pragma message("------> Release.")
#else
	#pragma comment(lib,"mylib_d")
	#pragma message("------> Debug.")
#endif

Amuses-toi bien, il y a des choses très intéressantes à faire avec les directives #pragma.

[Gourbish]

Grand merci à toi pour toutes ces explications.

Je vais essayer tout ça et faire quelques recherches pour approfondir le "truc".

Bonne fin de soirée/nuit.

Gourbish

[Arno_22]

Bonjour,

J'ai suivi avec attention vos échanges et je suis intéressé par l'intégration du code d'une librairie dans une autre librairie, non pas par les propriétés du projet VC, mais par les pragmas !

Est-ce réellement possible (mes premiers essais sont des échecs) ? Et, est-ce vraiment propre ?

Vous remerciant par avance...

[Mac LAK]

Prenons le cas suivant : Une application A, qui requiert une librairie L1 de façon explicite, et une librairie L2 par liens implicites de dépendance de L2.

Donc : A <-- L1 <-- L2

Sans les #pragma, tu es tenu de référencer les deux librairies de façon explicite au niveau de l'édition de liens de A, même si tu ne sais pas vraiment pourquoi tu as besoin de L2.

Donc : A <-- L1 (EXplicite) + A <-- L2 (EXplicite).

Avec les pragmas, tu peux rendre la dépendance à L2 implicite, et surtout, automatique.

Donc : A <-- L1 (EXplicite) + A <-- L2 (IMplicite).

Si tu distribues la librairie L1 avec sa dépendance (L2), tu as bien l'effet recherché : pour pouvoir linker L1, il te faudra spécifier son répertoire, qui contient également L2. Donc, le linker trouvera L2 tout seul car :
- Il a vu une directive #pragma pour effectuer le link,
- La librairie est dans ses chemins connus.
Cela te permet de déployer ta librairie à l'endroit que tu veux, mais cela oblige l'utilisateur à spécifier manuellement le chemin où il a installé ta librairie.

Pour aller plus loin, tu peux mettre L1 en autolink également, avec un #pragma également.

Donc : A <-- L1 (IMplicite) + A <-- L2 (IMplicite).

Dans ce dernier cas, le problème est que ton linker ne possèdera peut-être pas les chemins adéquats pour trouver l'une ou l'autre librairie. Dans un tel cas de figure, il te faudra impérativement déployer tes librairies dans un répertoire déjà connu, c'est à dire ceux internes à Visual Studio, de façon à ce qu'il puisse les trouver sans intervention ni modification des chemins du projet. En ce cas, il est souhaitable de déployer également les entêtes dans ces mêmes chemins, comme sous-répertoires des chemins de base.


Par contre, dans TOUS les cas, cela ne te permet PAS d'inclure L2 "dans" L1 au niveau binaire : tu devras TOUJOURS fournir les deux fichiers .LIB de façon séparée, mais l'utilisateur peut être déchargé des étapes suivantes :

• Inclusion manuelle de L2.
• Inclusion manuelle de L1.
• Spécification des chemins d'installation de la librairie.
• Spécification des chemins d'entêtes de la librairie.

A toi de voir après ce que tu veux épargner à l'utilisateur... Si tu installes ta librairie et tes entêtes dans les chemins de VS et que tu utilises correctement les #pragma, il peut tout simplement n'avoir RIEN d'autre à faire que le #include de ta librairie.

[Arno_22]

OK, merci pour ta réponse...

Nous pouvons donc dire que l'utilisation du "pragma", solution 1, n'est pas équivalente à la spécification d'une librairie dans le champ "Dépendances Supplémentaires" (de l'onglet "Générateur de bibliothèques" des propriétés de la librairie 1), solution 2.
Car, cette dernière a pour effet d'ajouter le code de la librairie 2 au sein de la librairie 1, contrairement à la première solution. Il n'y a donc plus qu'une librairie accompagnée de son(ses) header(s) à fournir aux applications utilisatrices. Tu confirmes ?

[Mac LAK]

Car, cette dernière a pour effet d'ajouter le code de la librairie 2 au sein de la librairie 1, contrairement à la première solution. Il n'y a donc plus qu'une librairie accompagnée de son(ses) header(s) à fournir aux applications utilisatrices. Tu confirmes ?

Heu, non, pas à ma connaissance du moins. Il n'y a pas de phase d'édition de liens lors de la construction d'une librairie statique.

Donc, à part le code générable à partir des headers exclusivement, AUCUN code compilé de L2 ne sera intégré à la librairie L1, dépendances ou pas. J'ai le cas concret sur mes projets, où je dépends de pas mal de librairies statiques "en cascade" : je te promets que je suis obligé de linker chaque librairie explicitement, que ce soit au niveau des exécutables ou via des #pragma.

La ligne "Dépendances supplémentaires" que tu cites est, normalement, l'exact équivalent d'un #pragma : cela RAJOUTE la librairie spécifiée (L2, donc) à l'édition de liens d'un programme utilisant L1 (celle pour laquelle tu as renseigné ce champ avec le nom de L2). Mais si L2 est absente, tu auras une erreur à l'édition de liens du programme, et ceci via les deux méthodes.

Toutefois, le champ "Dépendances supplémentaires" ne fonctionne correctement QUE si la dépendance est faite au niveau de la solution, projet par projet. Si tu fournis ta librairie sous forme "headers + fichier .LIB", il est "perdu" et seul le #pragma pourra être utilisé.

[Arno_22]

Je suis un peu perdu...

J'ai pourtant l'habitude de fonctionner comme cela (solution 2) et je t'assure que çà fonctionne bien. Il est également possible de spécifier une librairie au sein d'un projet directement dans l'explorateur de solution. Ça revient au même (en termes de résultat, la libraire "2" est incluse dans la librairie "1"!). D'ailleurs, la taille de la librairie "1" atteste de l'encapsulation de la librairie "2".

Par contre, si tu n'utilises que le header de la librairie 2 pour compiler la librairie 1 (spécification des méthodes), il est indispensable de fournir la librairie à l'application (que vous appeliez Z) pour que l'édition de lien soit un succès ! Et cela sans jamais spécifier "pragma comment(lib,..." où que se soit !

Donc, il y a un truc qui m'échappe !
Pardon, c'est vrai que j'ai légèrement dérivé par rapport au sujet de base !

Je te remercie du temps passé pour me répondre...

[Mac LAK]

J'ai pourtant l'habitude de fonctionner comme cela (solution 2) et je t'assure que çà fonctionne bien. Il est également possible de spécifier une librairie au sein d'un projet directement dans l'explorateur de solution. Ça revient au même (en termes de résultat, la libraire "2" est incluse dans la librairie "1"!). D'ailleurs, la taille de la librairie "1" atteste de l'encapsulation de la librairie "2".

Au niveau de l'explorateur de solutions, tu n'as besoin que de cocher les dépendances de projet : ainsi, tu n'as même pas besoin de spécifier les noms des librairies, ou quoi que ce soit d'autre à part les chemins des headers.
En général, c'est la méthode que j'utilise, donc la dépendance entre projets au sein d'une même solution.

Après, je n'ai jamais vu de .LIB "concaténé" à un autre de façon automatique, mais peut-être est-ce une nouveauté... Quelle version de VS utilises-tu ?

Quel que soit le cas, ce n'est pas très bon côté gestion de configuration : cela va "forcer" des modifications de L1 alors que seul L2 est impacté... Difficile d'isoler les modifications réelles, dans un tel cas.

Par contre, si tu n'utilises que le header de la librairie 2 pour compiler la librairie 1 (spécification des méthodes), il est indispensable de fournir la librairie à l'application (que vous appeliez Z) pour que l'édition de lien soit un succès ! Et cela sans jamais spécifier "pragma comment(lib,..." où que se soit !

Attention : le #pragma n'est PAS obligatoire, ce n'est qu'une alternative à cette information de librairie dans la configuration "Édition de liens" de l'exécutable appelant.
Pour ma part, j'utilise le #pragma pour les librairies "hors projet", celles qui ne sont pas recompilées systématiquement.

Pardon, c'est vrai que j'ai légèrement dérivé par rapport au sujet de base !

Au pire, demande à un modérateur de séparer le sujet.

[Arno_22]

J'espère qu'on se comprend bien...

Au niveau de l'explorateur de solutions, tu n'as besoin que de cocher les dépendances de projet : ainsi, tu n'as même pas besoin de spécifier les noms des librairies, ou quoi que ce soit d'autre à part les chemins des headers.
En général, c'est la méthode que j'utilise, donc la dépendance entre projets au sein d'une même solution.

Je suis complètement d'accord. C'est ce qu'il faut faire si tu as les sources de la librairie 2 !

Après, je n'ai jamais vu de .LIB "concaténé" à un autre de façon automatique, mais peut-être est-ce une nouveauté... Quelle version de VS utilises-tu ?

J'utilise VS8 (2005). Mais ce n'est pas une nouveauté. Si tes projets sont regroupés au sein d'une même solution et que tu règles la dépendance des projets, ca revient au même que de spécifier une librairie dans l'onglet cité précédemment, sous réserve de répondre "oui" au champ "Dépendances de bibliothèque de lien". Pour t'en assurer, tu peux regarder dans les lignes de commandes correspondantes - les librairies générées par les projets liés en dépendance sont spécifiées.

D'ailleurs la clé de mon problème, c'est peut être ce champ (Dépendances de bibliothèque de lien) qui aurait une équivalence en "pragma" !?

Quel que soit le cas, ce n'est pas très bon côté gestion de configuration : cela va "forcer" des modifications de L1 alors que seul L2 est impacté... Difficile d'isoler les modifications réelles, dans un tel cas.

Je suis d'accord. Mais le but est de "cacher" complètement L2 et de charger L2 ou L2' directement dans le code et non pas dans les propriétés du projet !

[Mac LAK]

Je suis complètement d'accord. C'est ce qu'il faut faire si tu as les sources de la librairie 2 !

Pas forcément : pour des raisons de temps de compilation et/ou de librairie située dans une gestion de configuration différente / commune, tu peux ne pas vouloir la recompiler systématiquement, que tu aie les sources ou pas.

Pour t'en assurer, tu peux regarder dans les lignes de commandes correspondantes - les librairies générées par les projets liés en dépendance sont spécifiées.

OK, mais cela ne provoque pas de "concaténation" des librairies statiques : mes .LIB sont liés ainsi, et n'augmentent pas d'un octet si je coche (ou pas !) une dépendance... C'est l'exécutable (ou la DLL) hôte qui va avoir, dans sa ligne de commande, TOUTES les librairies statiques en dépendance.

D'ailleurs la clé de mon problème, c'est peut être ce champ (Dépendances de bibliothèque de lien) qui aurait une équivalence en "pragma" !?

C'est normalement strictement équivalent, et avec le même effet : t'as besoin des deux librairies, simplement, avec le pragma, tu n'as pas besoin du projet de L2.

Je suis d'accord. Mais le but est de "cacher" complètement L2 et de charger L2 ou L2' directement dans le code et non pas dans les propriétés du projet !

Si tu veux planquer L2 à 100%, tu n'as qu'une seule et unique option : faire une DLL. C'est le seul moyen fiable, le reste, ce sera toujours soit avec de multiples .LIB (qui peuvent être linkés de façon totalement transparente, donc), soit avec une bidouille infecte (pas conseillé).

[Arno_22]

Bon ben, nous n'arrivons pas nous comprendre... J'intègre des librairies dans des librairies depuis des années et ca fonctionne très bien (et il n'y a pas de bidouille infecte).
J'ai au moins la réponse à ma question sur les "pragmas". Les fonctionnalités sont différentes.
Je te remercie pour ton aide.

[Mac LAK]

Bon ben, nous n'arrivons pas nous comprendre... J'intègre des librairies dans des librairies depuis des années et ca fonctionne très bien (et il n'y a pas de bidouille infecte).

C'est justement ça qui est étrange : je fais de même, et je n'ai JAMAIS vu d'intégration automatique d'une librairie statique dans une autre librairie statique... De toutes façons, cela peut poser des problèmes non négligeables de distribution : si tu n'as pas les sources de la librairie que l'on a appelée L2, tu n'as en général pas le droit non plus de la distribuer de façon modifiée, et tu peux provoquer des "Duplicate symbols" dans l'exécutable final.
Après, tu fais comme tu le sens bien sûr, mais autant je vois le paquet de problèmes que pourrait poser une librairie "unique" composée de plusieurs librairies statiques, autant je n'arrive pas à y voir le moindre avantage...

J'ai au moins la réponse à ma question sur les "pragmas". Les fonctionnalités sont différentes.

Le #pragma est un ordre de link d'une librairie statique (qui peut bien sûr être la librairie d'importation d'une DLL), vue au niveau de la compilation et, en général, au travers du header principal de ladite librairie. Ni plus, ni moins.

Je te remercie pour ton aide.

De rien.

[Arno_22]

C'est bien ce que je disais nous n'arrivons pas à nous comprendre...

Le sujet n'est pas de savoir s'il existe un intérêt quelconque. Ça dépend des projets et de ce qui doit être fait, de la disponibilité et de la protection des sources...
La fonctionnalité existe bien. Je voulais savoir si le "pragma" le faisait. La réponse est non !

Merci encore !

[Mac LAK]

Le sujet n'est pas de savoir si tu y trouves un intérêt quelconque.

Disons plutôt que lorsque quelqu'un choisis une "mauvaise" solution, c'est quand même normal de le lui dire et de lui expliquer les problèmes potentiels que cela peut poser derrière... Je te promets que c'est hélas un cas très fréquent sur le forum.

Après, on n'oblige à rien, ni moi, ni personne, mais c'est normal de dire à quelqu'un "ta solution pose des problèmes que tu n'as pas envisagés" !

Ça dépend de tes projets et de ce que tu as à faire, de la disponibilité et de la protection des sources...

Comme je te le disais, je n'ai jamais eu ce besoin, même sur des projets classés CD et/ou avec sources totalement fermés.

Les problèmes derrière sont, principalement, le fait de ne pas avoir à revalider certaines parties qui n'ont pas évolué binairement (chose loin d'être triviale avec une "super librairie" concaténée), les licences de diffusion de librairies tierces, les duplications de symboles potentielles si l'on "masque" une librairie au sein d'une autre, et le manque de portabilité de la technique.

Bonne continuation !

[Arno_22]

Merci et bonne continuation aussi !