Choix des symboles à l'edition des liens.

Fermé
Char Snipeur Messages postés 9696 Date d'inscription vendredi 23 avril 2004 Statut Contributeur Dernière intervention 3 octobre 2023 - 11 mars 2013 à 15:32
 Utilisateur anonyme - 12 mars 2013 à 08:50
Bonjour,
soit 4 fichiers :
main.cpp
#include <iostream>
void fct();
struct A{A()};
extern Aa;
int main()
{
    fct();
    std::cout<<lang(&a)<<std::endl;
    return 0;
}

__________________
fct.cpp
#include <iostream>
void fct(){std::cout<<"fct coucou du cc\n";};

__________________
construction.cc :
#include <iostream>
struct A{
A() {std::cout<<"coucou du cc\n";};
A a;

__________________
lib.cc :
#include <iostream>
struct A{
A() {std::cout<<"coucou du lib\n";};
A a;
void fct(){std::cout<<"fct coucou du lib\n";};

______
avec lib.cc on fait une bibliothèque statique liblib.a
on compile toutes les sources : g++ -c *.c* pour avoir les .o associés.

De la on considère plusieurs méthodes de compilation finale, selon la fonction fct et le constructeur A() que l'on veux inclure.:
g++ main.o -L. -llib -o test
g++ main.o fct.o -L. -llib -o test
g++ main.o construction.o -L. -llib -o test
g++ main.o fct.o construction.o -L. -llib -o test

Sur ces 4 lignes de commande, seul la première et la dernière fonctionnent. La deuxième renvoi comme erreur que fct() est définie plusieurs fois, et la troisième que 'a' est défini plusieurs fois.
Bef, je ne comprends pas pourquoi il est capable de masquer les deux fonctions de la bibliothèque (dernière ligne de commande), mais qu'il est incapable de masquer dans les deux autres cas...
C'est comme si soit il prenait tout les symboles de la bibliothèque, soit aucun.
Je n'arrive pas à trouver de base théorique sur ce qui ce passe durant cet édition des liens.
Si vous pouviez m'aider à comprendre, merci à vous.


A voir également:

5 réponses

Utilisateur anonyme
11 mars 2013 à 15:58
salut,

Sans rentrer dans les détails car je ne peux pas tester, mais je trouve etrange que tu n'ai pas de surcharge (tu déclare la même méthode avec les mêmes paramètres sans rien indiquer d'autre)

as-tu fais exprès de ne pas utiliser de #define et #ifndef ?
0
Utilisateur anonyme
11 mars 2013 à 16:03
Bonjour

À l'intérieur d'une bibliothèque, il y a encore la trace des fichiers sources d'où viennent les définitions. L'éditeur de lien prend tout ou rien d'un fichier compilé. Ça explique très bien le comportement que tu observes.
Tu aurais dû créer ta bibliothèque à partir de fct.o et de construction.o. Dans ce cas, les deux définitions provenant de deux compilation différentes, seraient bien indépendantes, et l'éditeur de lien ne prendrait que celle dont il a besoin.
0
Char Snipeur Messages postés 9696 Date d'inscription vendredi 23 avril 2004 Statut Contributeur Dernière intervention 3 octobre 2023 1 297
11 mars 2013 à 16:11
merci de ta réponse le père, ça confirme mes craintes...
Ce bout de code n'est qu'un démonstrateur, mon vrai problème concerne un programme de plusieurs centaines de fichiers sur lequel je fais des patch.

L'éditeur de lien prend tout ou rien d'un fichier compilé., ok, c'est ce à quoi j'étais arrivé aussi comme conclusion, mais aurais tu une doc qui explique ces choix du compilateur (de l'éditeur des liens précisément) ? Car j'ai un autre vrai problème, où le .o est ignoré au profit du .a, mais je n'arrive pas faire de démonstrateur.
Merci.
0
Utilisateur anonyme
11 mars 2013 à 16:15
essaye :

#ifndef iostream
#include <iostream>
#define iostream
#endif


pour chaque fichier qui inclue iostream
0
Utilisateur anonyme
11 mars 2013 à 16:22
Je n'ai pas de doc, seulement des connaissances qui ne sont pas vraiment de la dernière fraîcheur ;)
Mais en principe, l'éditeur de liens cherche à résoudre tous les symboles en premier lieu dans les fichiers objet qui lui sont soumis, puis dans les bibliothèques.
Je veux bien croire qu'il existe des cas tordus où les choses ne sont pas si simples (par exemple : un symbole est défini dans un fichier objet ET en bibliothèque, mais n'est appelé que depuis la bibliothèque : lequel est pris ???)
0
Utilisateur anonyme
11 mars 2013 à 16:24
pas en c \o/
0
Utilisateur anonyme
11 mars 2013 à 16:24
ou alors avec des compilateurs fais pour, mais quand j'ai appris le c fallait faire très attention aux multi inclusions ;)
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
Char Snipeur Messages postés 9696 Date d'inscription vendredi 23 avril 2004 Statut Contributeur Dernière intervention 3 octobre 2023 1 297
11 mars 2013 à 21:15
nagashima, tu n'as pas compris de quoi nous parlions. Le problème vient de l'édition des liens, c'est à dire bien après une quelconque inclusion.
En plus, les chiens de garde sont mis dans iostream, pas besoin d'en rajouter. Mais merci de ton aide ;-)
0
Utilisateur anonyme
12 mars 2013 à 08:50
ah autant pour moi =)
(par contre tu m'apprend un truc ! je dormirai moins bête =p je pensais que dans tous les cas la multi inclusion était à gérer par le développeur en c, fin dans le pire des cas c'est une sécurité inutile quoi ^^)
0