[MSVC8] Linker des librairies statique dans une librairie statique

Version imprimable

09/03/2008, 17h51
5:35pm

[MSVC8] Linker des librairies statique dans une librairie statique

Bonjour,

Je travaille sur une librairie statique, qui depend elle meme d'autres librairies statique.

L'executable utilisant ma librairie foire au linkage, car elle reclame les librairies dont ma librairie est dependante.

Je cherche donc a inclure ses dependance de maniere a ce que l'executable n'aie besoin que de ma librairie.
J'ai essaye de changer les options lors de la compilation de ma librairie, mais rien n'y fait...

Existe t-il une solution a ca, ou devrais-je me resoudre a faire un dll ?

merci =)
09/03/2008, 17h55
Matthieu Brucher

Ce n'est pas possible, il me semble (mais je peux me tromper ;)). Tu dois inclure à la fin la totalité des bibliothèques. Un des avantages des bibliothèques statiques est de ne pas nécessiter une édition des liens complètes, contrairement aux bibliothèques dynamiques.
09/03/2008, 17h57
5:35pm

merci pour cette reponse rapide :)

mais a voir la reponse je suis un peu deg lol
09/03/2008, 19h19
Mat007

Salut,

Tu vas dans les propriétés du projet et dans Librarian tu ajoutes les .lib dans Additional Dependencies (la 2e ligne).

MAT.
09/03/2008, 19h41
babar63

Citation:

Envoyé par Matthieu Brucher

Ce n'est pas possible, il me semble (mais je peux me tromper ;)). Tu dois inclure à la fin la totalité des bibliothèques. Un des avantages des bibliothèques statiques est de ne pas nécessiter une édition des liens complètes, contrairement aux bibliothèques dynamiques.

Si la bibliothèque statique est liée directement lors de la compilation d'une autre bibliothèque(statique ou dynamique), pourquoi il faudrait inclure la première lib dans le projet utilisant la deuxième...? Pour moi, c'est justement l'avantage d'une lib statique, je me trompe?

Ce n'est pas justement la librairie dynamique qui ne nécessite pas une édition des liens complètes... :roll:...
09/03/2008, 20h40
5:35pm

Citation:

Envoyé par Mat007

Salut,

Tu vas dans les propriétés du projet et dans Librarian tu ajoutes les .lib dans Additional Dependencies (la 2e ligne).

MAT.

c'est bien ce que je fais
J'ai aussi mis "Link Library dependencies" a "yes"...

Citation:

Si la bibliothèque statique est liée directement lors de la compilation d'une autre bibliothèque(statique ou dynamique), pourquoi il faudrait inclure la première lib dans le projet utilisant la deuxième...? Pour moi, c'est justement l'avantage d'une lib statique, je me trompe?

eh bien cette lib est un framework qui encapsule pas mal de choses, et ca m'embete de specifier toutes ces dependances dans l'appli, ca fait assez bordelique =)
09/03/2008, 20h53
ram-0000

Citation:

Envoyé par Matthieu Brucher

Ce n'est pas possible, il me semble (mais je peux me tromper ;)). Tu dois inclure à la fin la totalité des bibliothèques. Un des avantages des bibliothèques statiques est de ne pas nécessiter une édition des liens complètes, contrairement aux bibliothèques dynamiques.

Je confirme

Le link statique se finalise lors de la création de l'exécutable donc il faut la liste des toutes les librairies statiques (même celles qui dépendent/sont utilisées par une autre librairie intermédiaire)

Par contre, je ne sais pas pourquoi il faut ajouter les librairies statiques lors de la création des librairies statiques intermédiaires. Tu as essayé de créer cette librairie intermédiaire sans lier avec les autres librairies ?
09/03/2008, 21h04
5:35pm

mmm un detail que j'aurais du preciser, j'ai pas mal de warning a la compilation de la librairie:

winmm.lib(WINMM.dll) : warning LNK4221: no public symbols found; archive member will be inaccessible

ca le fait pour chaque librairie tierce...

EDIT

selon msdn: http://support.microsoft.com/kb/815773:

Citation:

This article discusses the Linker Tools Warning LNK4221 message. This warning occurs when you try to add resources to a static library. The linker tries to add resources in a publicly accessible way. However, the linker fails and you receive the following warning message:
warning LNK4221: no public symbols found; archive member will be inaccessible
An object file was added to an archive library that has no public symbols. The object is not accessible by using subsequent linker commands.

et ce lien dit :

Citation:

Linker Tools Warning LNK4221:
A .obj file with no public symbols was added to a library. The symbols in the object will not be accessible in subsequent linker operations that include the .lib.

To resolve this warning, do not link a .obj file with no public symbols into a library.

donc en gros il faut des symboles public, et je ne sais pas comment ca marche... ou alors c'est vraiment pas possible...
10/03/2008, 00h36
Mat007

Citation:

Envoyé par 5:35pm

c'est bien ce que je fais

Et bien dans ce cas tu n'as pas besoin des .lib que tu listes dans cette case lors de l'édition des liens finale, ils sont inclus dans ton .lib intermédiaire. Tu peux le vérifier en observant la différence de taille du .lib et/ou avec un dumpbin /all truc.lib | grep ton_symbol.

Par contre oui c'est quand même très risqué : si le client utilise par ailleurs les mêmes bibliothèques dans des versions différentes, ça va faire n'importe quoi au final.

Citation:

Envoyé par 5:35pm

J'ai aussi mis "Link Library dependencies" a "yes"...

Non ça n'a rien à voir ça par contre.

MAT.
10/03/2008, 02h21
babar63

Citation:

Envoyé par ram_0000

Je confirme

Le link statique se finalise lors de la création de l'exécutable donc il faut la liste des toutes les librairies statiques (même celles qui dépendent/sont utilisées par une autre librairie intermédiaire)

Par contre, je ne sais pas pourquoi il faut ajouter les librairies statiques lors de la création des librairies statiques intermédiaires. Tu as essayé de créer cette librairie intermédiaire sans lier avec les autres librairies ?

Le code d'une librairie statique est bien lié à la compilation, donc si on l'utilise dans un projet on doit linker la librairie. De même, si une librairie intermédiaire est déjà linkée avec une autre alors ce n'est plus la peine de la linker pour les futurs projets, en clair, ce n'est pas obligatoire de linker une librairie si d'autre librairie linkée le font déjà. Voilà un exemple pour être plus claire :

Premier projet : Librairie statique Lib1.lib, défini la classe MaClasse1(MaClasse1.h, MaClasse1.cpp)

Deuxième projet : Librairie statique Lib2.lib linkée avec Lib1.lib, défini la classe MaClasse2(MaClasse2.h, MaClasse2.cpp)

Exécutable : linké avec Lib2.lib, utilise MaClasse1 et MaClasse2...

Citation:

winmm.lib(WINMM.dll) : warning LNK4221: no public symbols found; archive member will be inaccessible

Il me semble que ce warning signifie que tu inclue dans ta librairie une classe qui ne pourra être accédée de l'extérieur car tu n'a aucun symbole(constructeur, donnée, fonction) défini en public...

Citation:

Envoyé par 5:35pm

c'est bien ce que je fais

Dans ce cas, quelle est l'erreur que tu obtiens...:roll:
12/03/2008, 00h28
5:35pm

Citation:

Dans ce cas, quelle est l'erreur que tu obtiens...

LINK : fatal error LNK1104: cannot open file 'xxxx.lib'

ou xxxx est une lib utilise par ma propre librairie...
12/03/2008, 09h31
babar63

Citation:

Envoyé par 5:35pm

LINK : fatal error LNK1104: cannot open file 'xxxx.lib'

C'est toi qui à créé cette lib? Si c'est le cas il se peut qu'il ne trouve pas ta librairie. En dessous de "dépendances supplémentaires" tu as normalement "répertoires de bibliothèques supplémentaires", commences par mettre le path absolu pour tester ça devrait fonctionner.
Si ce n'est pas le cas peux tu donner le nom de la librairie?
12/03/2008, 13h21
Mat007

Citation:

Envoyé par babar63

Le code d'une librairie statique est bien lié à la compilation, donc si on l'utilise dans un projet on doit linker la librairie. De même, si une librairie intermédiaire est déjà linkée avec une autre alors ce n'est plus la peine de la linker pour les futurs projets, en clair, ce n'est pas obligatoire de linker une librairie si d'autre librairie linkée le font déjà.

Il n'y a pas de phase d'édition des liens quand on crée une bibliothèque statique, d'ailleurs dans la configuration du projet on trouve 'Librarian' (lib.exe) et non 'Linker' (link.exe).
Il faut voir un .lib comme une sorte de collection de .obj, chaque .obj est mis dans le .lib créé par la bibliothèque statique du .vcproj auquel il appartient et le tout est assemblé tout à la fin lors de l'édition des liens de l'exécutable (ou de la bibliothèque dynamique).

Il faut donc fournir tous les .obj lors de l'édition des liens pour faire l'exécutable, en général on fournit tous les .lib mais ce n'est pas obligé.
En effet il est tout à fait possible de simplifier le nombre de .lib finaux que l'utilisateur devra manipuler. Il suffit de mettre mettre un ou plusieurs .lib "dans" un autre .lib en utilisant le procédé que j'ai décrit.
Si on regarde la ligne de commande générée on voit que le .lib est tout bêtement sur la ligne de commande au même titre que les .obj : lib.exe accepte les .obj et les .lib (cf. http://msdn2.microsoft.com/en-us/lib...5t(VS.80).aspx dont "The files can be COFF object files, 32-bit OMF object files, or existing COFF libraries.").

Citation:

Envoyé par 5:35pm

LINK : fatal error LNK1104: cannot open file 'xxxx.lib'

Il ne faut pas mettre xxxx.lib dans la liste des "input" du "linker" de l'application finale puisque il est inclus dans ton .lib intermédiaire.

MAT.
12/03/2008, 13h42
babar63

Citation:

Envoyé par Mat007

Il n'y a pas de phase d'édition des liens quand on crée une bibliothèque statique, d'ailleurs dans la configuration du projet on trouve 'Librarian' (lib.exe) et non 'Linker' (link.exe).
Il faut voir un .lib comme une sorte de collection de .obj, chaque .obj est mis dans le .lib créé par la bibliothèque statique du .vcproj auquel il appartient et le tout est assemblé tout à la fin lors de l'édition des liens de l'exécutable (ou de la bibliothèque dynamique).

Il faut donc fournir tous les .obj lors de l'édition des liens pour faire l'exécutable, en général on fournit tous les .lib mais ce n'est pas obligé.
En effet il est tout à fait possible de simplifier le nombre de .lib finaux que l'utilisateur devra manipuler. Il suffit de mettre mettre un ou plusieurs .lib "dans" un autre .lib en utilisant le procédé que j'ai décrit.
Si on regarde la ligne de commande générée on voit que le .lib est tout bêtement sur la ligne de commande au même titre que les .obj : lib.exe accepte les .obj et les .lib (cf. http://msdn2.microsoft.com/en-us/lib...5t(VS.80).aspx dont "The files can be COFF object files, 32-bit OMF object files, or existing COFF libraries.").

Oui je n'entrais pas en contradiction avec ça ( enfin je crois, je me suis tellement mal exprimé que j'ai dû mal à me comprendre :aie: )
:dehors:

Citation:

Il ne faut pas mettre xxxx.lib dans la liste des "input" du "linker" de l'application finale puisque il est inclus dans ton .lib intermédiaire

En effet c'est inutile mais je ne crois pas que ça génère une erreur... je me trompe?
12/03/2008, 16h56
Mat007

Citation:

Envoyé par babar63

En effet c'est inutile mais je ne crois pas que ça génère une erreur... je me trompe?

Si linker ne trouve pas un des fichiers il sort avec une erreur, qu'il en ait besoin pour des symboles ou pas (en fait il n'a pas encore essayé de lier) : essaye de rajouter pipo.lib à l'édition des liens pour voir. :)

MAT.
12/03/2008, 20h11
babar63

Ce n'est pas ce que je voulais dire, j'ai du mal à me faire comprendre en ce moment (on va dire que c'est la fatigue :?) si je reprend mon exemple :

Citation:

Envoyé par babar63

Premier projet : Librairie statique Lib1.lib, défini la classe MaClasse1(MaClasse1.h, MaClasse1.cpp)

Deuxième projet : Librairie statique Lib2.lib linkée avec Lib1.lib, défini la classe MaClasse2(MaClasse2.h, MaClasse2.cpp)

Exécutable : linké avec Lib2.lib, utilise MaClasse1 et MaClasse2...

Ce que je voulais dire c'est que si l'exécutable link aussi lib1.lib, bien que ce soit inutile ça ne génère pas d'erreur. Pour ce qui est de trouver la librairie c'est autre chose, c'est pour ça d'ailleurs que j'ai écrit plus loin :

Citation:

Envoyé par babar63

il se peut qu'il ne trouve pas ta librairie. En dessous de "dépendances supplémentaires" tu as normalement "répertoires de bibliothèques supplémentaires", commences par mettre le path absolu pour tester ça devrait fonctionner
13/03/2008, 00h19
Mat007

Citation:

Envoyé par babar63

Ce que je voulais dire c'est que si l'exécutable link aussi lib1.lib, bien que ce soit inutile ça ne génère pas d'erreur.

Ah oui pardon j'avais pas compris ça.
Effectivement tu peux ajouter plein de .lib inutiles pour l'édition des liens, ça ralentira un (tout petit) peu mais ça ne fera en effet pas d'erreur.

MAT.
14/06/2008, 00h26
xurei

Bonjour,

J'aimerais faire la même chose avec code::blocks, mais je ne trouve pas comment faire... Quelqu'un saurait-il m'aider ?

Merci d'avance !
14/06/2008, 10h49
koala01
Citation:

Envoyé par xurei

Bonjour,

J'aimerais faire la même chose avec code::blocks, mais je ne trouve pas comment faire... Quelqu'un saurait-il m'aider ?

Merci d'avance !
1. Suivre le menu Projects-->build options
2. Sélectionner sur le coté gauche la cible qui a besoin de la bibliothèque (tout le projet, debug, relase ou cible personnelle)
3. choisir l'onglet linker settings
4. ajouter la bibliothèque dans la liste de gauche
5. (éventuellement rajouter le dossier dans lequel se trouve la bibliothèque dans l'onglet search directories, sous onglet linker)
14/06/2008, 11h01
Laurent Gomila

A ma connaissance ce n'est pas possible directement. Le seul moyen est de le faire à la main (les bibliothèques statiques ne sont que des archives de fichiers objets).

Si tu es sous Linux, ou si tu possèdes un environnement Linux sous Windows (CYGWIN), tu peux utiliser cette commande pour ajouter le contenu de lib_src.a à lib_dest.a :

Code:

ar xv lib_src.a | cut -f3 -d ' ' | xargs ar rvs lib_dest.a
14/06/2008, 12h05
Aurelien.Regat-Barrel

Si quand tu generes un .lib tu specifies d'autres .lib avec lesquels "lier", ces .lib seront "recopies" dans ton .lib final, ce qui permet en effet de les encapsuler et de ne pas avoir a lier avec plus tard. Mais... Il est aussi facile de se retrouver par la suite avec des symboles definis de multiples fois, parce que l'utilisateur utilise une des libs que tu as "encapsule" dans ton .lib et link avec, ce qui fait echouer le link. Ou pire encore, il utilise une autre lib qui a elle aussi "encapsule" la meme lib... Donc prudence avec cette strategie :D