Ce qui est une référence non définie/externe non résolu symbole d'erreur et comment la corriger?

La compilation d'un programme C++ se déroule en plusieurs étapes, comme spécifié par 2.2 (crédits de Keith Thompson pour la référence):

La préséance entre les règles de syntaxe de la traduction est fixée par les phases suivantes [voir note de bas de page].

1. Physique du fichier source caractères sont mis en correspondance, la mise en œuvre définies de manière à la source de base de jeu de caractères
   (introduction de la nouvelle ligne de caractères de fin de ligne des indicateurs) si
   nécessaire. [SNIP]
2. Chaque occurrence d'un caractère barre oblique inverse (\) immédiatement suivie d'une nouvelle ligne de caractère est supprimé, l'épissage source physique des lignes de
   la forme logique de la source de lignes. [SNIP]
3. Le fichier source est décomposé en un prétraitement des jetons (2.5) et des séquences de caractères d'espacement (y compris les commentaires). [SNIP]
4. Prétraitement directives sont exécutées, macro invocations sont élargies, et _Pragma opérateur unaire expressions sont exécutées. [SNIP]
5. Chaque source de jeu de caractères membre dans un littéral de caractère ou une chaîne de caractères littérale, ainsi que chaque séquence d'échappement et universelle-personnage-nom
   un caractère littéral ou non raw littéral de chaîne est convertie
   le membre correspondant de l'exécution du jeu de caractères; [SNIP]
6. Adjacentes littéral de chaîne de tokens sont concaténées.
7. De caractères d'espacement séparant les jetons sont pas plus importante. Chaque prétraitement jeton est converti en un jeton. (2.7). L'
   résultant des jetons sont syntaxiquement et sémantiquement analysé et
   traduit comme une unité de traduction. [SNIP]
8. Traduit unités de traduction et d'instanciation unités sont combinées comme suit: [SNIP]
9. Toutes les références d'entité sont résolus. Bibliothèque de composants sont liés à satisfaire les exigences des références à des entités qui ne sont pas définis dans le
   traduction en cours. Tous ces traducteur de sortie est prélevé dans un
   programme image qui contient les informations nécessaires pour l'exécution de ses
   environnement d'exécution. (l'emphase est mienne)

[note de bas de page] Implémentations doivent se comporter comme si ces phases distinctes se produire, même si dans la pratique les différentes phases peuvent être pliés.

Spécifié des erreurs se produisent au cours de cette dernière étape de la compilation, plus communément appelée la liaison. Cela signifie essentiellement que vous avez compilé un groupe de fichiers de mise en œuvre dans les fichiers objets ou des bibliothèques et maintenant vous voulez les faire travailler ensemble.

Dire que vous avez défini symbole a dans a.cpp. Maintenant, b.cpp déclaré que symbole et l'a utilisé. Avant la liaison, il suppose simplement que ce symbole a été défini quelque part, mais il n'a pas encore de soins où. Le lien entre la phase est responsable de trouver le symbole et correctement le reliant à b.cpp (eh bien, en fait, à l'objet ou à la bibliothèque qui l'utilise).

Si vous êtes à l'aide de Microsoft Visual Studio, vous verrez que les projets génèrent .lib fichiers. Ceux-ci contiennent une table de symboles exportés, et une table de symboles importés. Les symboles importés sont résolues contre les bibliothèques de lien en face de vous, et les symboles exportés sont fournis pour les bibliothèques qui utilisent ce .lib (le cas échéant).

Des mécanismes similaires existent pour d'autres compilateurs/plates-formes.

Messages d'erreur courants error LNK2001, error LNK1120, error LNK2019 pour Microsoft Visual Studio et undefined reference to symbolName pour GCC.

Le code:

struct X
{
   virtual void foo();
};
struct Y : X
{
   void foo() {}
};
struct A
{
   virtual ~A() = 0;
};
struct B: A
{
   virtual ~B(){}
};
extern int x;
void foo();
int main()
{
   x = 0;
   foo();
   Y y;
   B b;
}

va générer les erreurs suivantes avec GCC:

/home/AbiSfw/ccvvuHoX.o: In function `main':
prog.cpp:(.text+0x10): undefined reference to `x'
prog.cpp:(.text+0x19): undefined reference to `foo()'
prog.cpp:(.text+0x2d): undefined reference to `A::~A()'
/home/AbiSfw/ccvvuHoX.o: In function `B::~B()':
prog.cpp:(.text._ZN1BD1Ev[B::~B()]+0xb): undefined reference to `A::~A()'
/home/AbiSfw/ccvvuHoX.o: In function `B::~B()':
prog.cpp:(.text._ZN1BD0Ev[B::~B()]+0x12): undefined reference to `A::~A()'
/home/AbiSfw/ccvvuHoX.o:(.rodata._ZTI1Y[typeinfo for Y]+0x8): undefined reference to `typeinfo for X'
/home/AbiSfw/ccvvuHoX.o:(.rodata._ZTI1B[typeinfo for B]+0x8): undefined reference to `typeinfo for A'
collect2: ld returned 1 exit status

et des erreurs similaires avec Microsoft Visual Studio:

1>test2.obj : error LNK2001: unresolved external symbol "void __cdecl foo(void)" (?foo@@YAXXZ)
1>test2.obj : error LNK2001: unresolved external symbol "int x" (?x@@3HA)
1>test2.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall A::~A(void)" (??1A@@UAE@XZ)
1>test2.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall X::foo(void)" (?foo@X@@UAEXXZ)
1>...\test2.exe : fatal error LNK1120: 4 unresolved externals

Les causes courantes comprennent:

• L'échec de lier des bibliothèques appropriées/fichiers d'objet ou de compiler des fichiers de mise en œuvre
• Déclaré et undefined variable ou de la fonction.
• Problèmes courants avec la classe-type de membres
• Modèle implémentations ne sont pas visibles.
• Les symboles ont été définies dans un programme C et utilisé dans du code C++.
• Incorrecte de l'importation/exportation de méthodes/classes entre les modules/dll. (MSVS spécifique)
• Circulaire de la bibliothèque de la dépendance
• undefined reference to `WinMain@16'
• Interdépendants de la bibliothèque de l'ordre
• Plusieurs fichiers source du même nom
• Erreur de frappe ou non, y compris les .lib extension lors de l'utilisation de l'option #pragma (Microsoft Visual Studio)
• Problèmes avec le modèle d'amis
• Incompatible UNICODE définitions

OriginalL'auteur Luchian Grigore

Défaut de lien contre appropriée bibliothèques d'objets les fichiers ou compiler des fichiers de mise en œuvre

Généralement, chaque unité de traduction va générer un fichier de l'objet qui contient les définitions des symboles définis dans cette unité de traduction.
À l'utilisation de ces symboles, vous avez un lien à l'encontre de ces fichiers objets.

Sous gcc vous devez spécifier tous les fichiers objets qui doivent être reliés à la ligne de commande, ou de compiler les fichiers de mise en œuvre ensemble.

g++ -o test objectFile1.o objectFile2.o -lLibraryName

La libraryName ici est juste le strict nom de la bibliothèque, sans une plate-forme spécifique ajouts. Donc, par exemple, sur Linux, les fichiers de bibliothèque sont généralement appelés libfoo.so mais vous auriez du écrire seulement -lfoo. Sur Windows que même fichier peut être appelé foo.lib, mais que vous souhaitez utiliser le même argument. Vous pourriez avoir à ajouter le répertoire où les fichiers peuvent être trouvés en utilisant -L‹directory›. Assurez-vous de ne pas écrire une espace après -l ou -L.

Pour XCode: Ajouter l'en-Tête Utilisateur Chemins de Recherche -> ajouter le Chemin de Recherche des bibliothèques -> faites glisser et déposez l'effectif de référence de la bibliothèque dans le dossier du projet.

Sous MSVS, les fichiers ajoutés à un projet automatiquement leurs fichiers objets liés ensemble et un lib le fichier généré (à usage commun). L'utilisation des symboles dans un projet distinct, vous feriez
besoin d'inclure le lib fichiers dans les paramètres du projet. Ceci est fait dans l'éditeur de liens de la section propriétés du projet, dans Input -> Additional Dependencies. (le chemin d'accès à la lib fichier doit être
ajouté dans Linker -> General -> Additional Library Directories) Lors de l'utilisation d'une bibliothèque tierce, qui est fourni avec un lib fichier, à défaut de le faire est généralement le résultat dans l'erreur.

Il peut aussi arriver que vous oubliez d'ajouter le fichier à la compilation, auquel cas le fichier de l'objet ne seront pas générées. Dans gcc vous ajoutez les fichiers à la ligne de commande. Dans MSVS ajouter le fichier au projet faire compiler automatiquement (bien que les fichiers peuvent, manuellement, soit individuellement exclu de la compilation).

Dans la programmation Windows, le signe révélateur que vous n'avez pas de lien nécessaire de la bibliothèque, c'est que le nom du symbole non commence avec __imp_. Recherchez le nom de la fonction dans la documentation, et il faut dire que la bibliothèque, vous devez utiliser. Par exemple, MSDN place les informations dans une boîte au fond de chaque fonction dans une section appelée "Bibliothèque".

OriginalL'auteur Luchian Grigore

L'ordre dans lequel interdépendants liés bibliothèques sont spécifié est incorrect.

L'ordre dans lequel les bibliothèques sont liées importe si les bibliothèques dépendent les uns des autres. En général, si la bibliothèque A dépend de la bibliothèque B, puis libA DOIT comparaître devant libB dans l'éditeur de liens drapeaux.

Par exemple:

//B.h
#ifndef B_H
#define B_H

struct B {
    B(int);
    int x;
};

#endif

//B.cpp
#include "B.h"
B::B(int xx) : x(xx) {}

//A.h
#include "B.h"

struct A {
    A(int x);
    B b;
};

//A.cpp
#include "A.h"

A::A(int x) : b(x) {}

//main.cpp
#include "A.h"

int main() {
    A a(5);
    return 0;
};

Créer les bibliothèques:

$ g++ -c A.cpp
$ g++ -c B.cpp
$ ar rvs libA.a A.o 
ar: creating libA.a
a - A.o
$ ar rvs libB.a B.o 
ar: creating libB.a
a - B.o

Compiler:

$ g++ main.cpp -L. -lB -lA
./libA.a(A.o): In function `A::A(int)':
A.cpp:(.text+0x1c): undefined reference to `B::B(int)'
collect2: error: ld returned 1 exit status
$ g++ main.cpp -L. -lA -lB
$ ./a.out

Donc, pour reprendre encore une fois, l'ordre NE question!

OriginalL'auteur Svalorzen

Symboles ont été définies dans un programme C et utilisé dans du code C++.

La fonction (ou une variable) void foo() a été défini dans un programme C et que vous essayez de l'utiliser dans un programme en C++:

void foo();
int main()
{
    foo();
}

Le C++ linker attend des noms de déformation, de sorte que vous avez à déclarer la fonction:

extern "C" void foo();
int main()
{
    foo();
}

De manière équivalente, au lieu d'être définies dans un programme C, la fonction (ou une variable) void foo() a été défini en C++, mais avec une liaison C:

extern "C" void foo();

et vous essayez de l'utiliser dans un programme en C++ en C++, la liaison.

Si une bibliothèque entière est inclus dans un fichier d'en-tête (et a été compilé en code C); l'inclure devra être comme suit;

extern "C" {
    #include "cheader.h"
}

OriginalL'auteur Luchian Grigore

Incorrecte de l'importation/exportation de méthodes/classes entre les modules/dll (compilateur spécifique).

MSVS vous oblige à spécifier les symboles à l'exportation et à l'importation à l'aide de __declspec(dllexport) et __declspec(dllimport).

Cette double fonctionnalité est généralement obtenue grâce à l'utilisation d'une macro:

#ifdef THIS_MODULE
#define DLLIMPEXP __declspec(dllexport)
#else
#define DLLIMPEXP __declspec(dllimport)
#endif

La macro THIS_MODULE ne seraient définies dans le module que les exportations de la fonction. De cette façon, la déclaration:

DLLIMPEXP void foo();

étend à

__declspec(dllexport) void foo();

et indique au compilateur d'exportation de la fonction, comme le module contient sa définition. Lors de l'inclusion de la déclaration dans un autre module, il permettrait d'augmenter de

__declspec(dllimport) void foo();

et indique au compilateur que la définition est dans l'une des bibliothèques liées à l'encontre (voir aussi 1)).

Vous pouvez de même importer/exporter des classes:

class DLLIMPEXP X
{
};

OriginalL'auteur Luchian Grigore

C'est l'un des plus troublantes que les messages d'erreur que chaque VC++ programmeurs ont vu et revu. Nous allons faire les choses clarté premier.

A. Quel est le symbole?
En bref, un symbole est un nom. Il peut être un nom de variable, un nom de fonction, un nom de classe, une définition de type nom, ou quoi que ce soit à l'exception de celles des noms et des signes qui appartiennent au langage C++. Il est défini par l'utilisateur ou introduite par une dépendance de la bibliothèque (un autre défini par l'utilisateur).

B. qu'est-Ce que de l'extérieur?
Dans VC++, chaque fichier source (.rpc.c,etc.) est considéré comme une unité de traduction, le compilateur compile une unité à la fois, et de générer un fichier objet(.obj) pour le courant de l'unité de traduction. (Notez que chaque fichier d'en-tête de ce fichier source inclus sera analysée et seront considérées comme faisant partie de cette unité de traduction)le Tout dans une unité de traduction est considérée comme interne, tout le reste est considéré comme externe. En C++, vous pouvez faire référence à un symbole externe en utilisant des mots-clés comme extern, __declspec (dllimport) et ainsi de suite.

C. Ce qui est de “résoudre”?
Résoudre est un liant à temps. Dans le rattachement du temps, de l'éditeur de liens tentatives pour trouver la définition externe pour tous les symboles dans des fichiers objets qui ne peuvent pas trouver sa définition à l'interne. Le champ d'application de ce processus de recherche, y compris:

• Tous les fichiers objets générés à la compilation du temps
• Toutes les bibliothèques (.lib) qui sont explicitement ou implicitement
  spécifié en tant que dépendances supplémentaires de cette demande de construire.

Ce processus de recherche est appelé à résoudre.

D. Enfin, pourquoi Symbole Externe non résolu?
Si le linker ne trouve pas la définition externe pour un symbole qui n'a pas de définition à l'interne, il signale un Symbole Externe non résolu erreur.

E. causes Possibles de LNK2019: Symbole Externe non résolu d'erreur.
Nous savons déjà que cette erreur est due à l'éditeur de liens ne trouve pas la définition de symboles externes, les causes possibles peuvent être classés comme:

1. Définition existe

Par exemple, si nous avons une fonction appelée foo définis dans a.cpp:

int foo()
{
    return 0;
}

Dans b.cpp nous voulons appeler la fonction foo, si on l'ajoute

void foo();

de déclarer la fonction foo(), et de l'appeler dans un autre corps de la fonction, dire bar():

void bar()
{
    foo();
}

Maintenant, quand vous construisez ce code, vous obtiendrez une erreur LNK2019 se plaindre que foo est un symbole non résolu. Dans ce cas, nous savons que les foo() a sa définition dans a.cpp mais différent de celui que nous appelons(différentes valeur de retour). C'est le cas de cette définition existe.

1. Définition n'existe pas

Si nous voulons appeler certaines fonctions dans une bibliothèque, mais la bibliothèque d'importation n'est pas ajouté dans le supplémentaires liste de dépendances (définie à partir de: Project | Properties | Configuration Properties | Linker | Input | Additional Dependency) de votre projet de création. Maintenant que l'éditeur de liens signaler un LNK2019 depuis la définition n'existe pas en courant à la recherche de la portée.

OriginalL'auteur Nima Soroush

Aussi si vous êtes en utilisant 3ème partie les bibliothèques assurez-vous d'avoir le bon 32/64 bits binaires

OriginalL'auteur Dula

Visual Studio NuGet package doit être mis à jour pour les nouveaux outils de la version

J'ai juste eu ce problème en essayant de lier libpng avec Visual Studio 2013. Le problème est que le fichier de package seulement eu des bibliothèques pour Visual Studio 2010 et 2012.

La bonne solution est de l'espoir que le développeur publie un package de mise à jour et de le mettre à niveau, mais il a travaillé pour moi par le piratage d'un supplément de réglage pour VS2013, pointant à la VS2012 fichiers de la bibliothèque.

J'ai édité le paquet (dans le packages dossier à l'intérieur de la solution du répertoire) en trouvant packagename\build\native\packagename.targets et à l'intérieur de ce fichier, la copie de tous les v110 sections. J'ai changé le v110 à v120 dans la condition uniquement pour les champs de être très prudent de quitter les chemins des fichiers tout comme v110. Cela a simplement permis de Visual Studio 2013 lien vers les bibliothèques pour l'année 2012, et dans ce cas, il a travaillé.

OriginalL'auteur Malvineous

Un bug du compilateur/IDE

J'ai récemment eu ce problème, et il s'est avéré c'était un bug dans Visual Studio Express 2013. J'ai dû supprimer un fichier source du projet et de l'ajouter de nouveau à surmonter le bug.

Étapes à suivre si vous croyez que ça pourrait être un bug dans le compilateur/IDE:

• Propre au projet (quelques IDEs ont une option pour ce faire, vous pouvez également
  faire manuellement en supprimant les fichiers d'objet)
• Essayez de démarrer un nouveau projet,
  copier tout le code source de la version originale.

OriginalL'auteur developerbmw

Utiliser l'éditeur de liens pour aider à diagnostiquer l'erreur

Plus modernes linkers inclure une option verbose qui imprime à des degrés divers;

• Lien invocation (ligne de commande),
• Des données sur ce que les bibliothèques sont inclus dans le lien de la scène,
• L'emplacement des bibliothèques,
• Chemins de recherche utilisé.

Pour gcc et clang; vous pouvez généralement ajouter -v -Wl,--verbose ou -v -Wl,-v à la ligne de commande. Plus de détails peuvent être trouvés ici,

• Linux ld page de man.
• LLVM l'éditeur de liens de la page.
• "Une introduction à la GCC" chapitre 9.

Pour MSVC, /VERBOSE (en particulier /VERBOSE:LIB) est ajouté à la ligne de commande de liaison.

• La page MSDN sur le /VERBOSE option de l'éditeur de liens.

OriginalL'auteur Niall

Un wrapper autour de GNU ld qui ne supportent pas de linker scripts

Certains .si les fichiers sont en fait GNU ld linker scripts, par exemple libtbb.donc fichier est un fichier texte ASCII avec ce contenu:

INPUT (libtbb.so.2)

Peu plus complexe construit peut pas en charge cette. Par exemple, si vous incluez -v dans les options du compilateur, vous pouvez voir que le mainwin gcc wrapper mwdip rejets linker script fichiers de commande à la sortie verbeuse liste de bibliothèques de lien. Un travail simple est de remplacer le linker script de commande d'entrée de fichier avec une copie du fichier au lieu (ou un lien symbolique), par exemple

cp libtbb.so.2 libtbb.so

Ou vous pouvez remplacer l'argument-l avec le chemin d'accès complet de l' .ainsi, par exemple, au lieu de -ltbb ne /home/foo/tbb-4.3/linux/lib/intel64/gcc4.4/libtbb.so.2

OriginalL'auteur JDiMatteo

Votre lien consomme bibliothèques avant que l'objet des fichiers qui parlent d'eux

• Vous essayez de compiler et lier votre programme avec le CCG de la chaîne d'.
• Votre lien spécifie que toutes les bibliothèques et la bibliothèque des chemins de recherche
• Si libfoo dépend libbar, alors votre lien correctement met libfoo avant libbar.
• Votre connexion échoue avec undefined reference to quelque chose erreurs.
• Mais tous les indéfini quelque choses sont déclarées dans l'en-tête des fichiers que vous avez
  #included et sont en fait définies dans les bibliothèques que vous liez.

Exemples sont en C. Elles pourraient tout aussi bien être C++

Un exemple minimal impliquant une bibliothèque statique que vous avez construit vous-même

my_lib.c

#include "my_lib.h"
#include <stdio.h>

void hw(void)
{
    puts("Hello World");
}

my_lib.h

#ifndef MY_LIB_H
#define MT_LIB_H

extern void hw(void);

#endif

eg1.c

#include <my_lib.h>

int main()
{
    hw();
    return 0;
}

Vous de construire votre bibliothèque statique:

$ gcc -c -o my_lib.o my_lib.c
$ ar rcs libmy_lib.a my_lib.o

Vous compilez votre programme:

$ gcc -I. -c -o eg1.o eg1.c

Vous essayez de faire le lien avec libmy_lib.a et de l'échec:

$ gcc -o eg1 -L. -lmy_lib eg1.o 
eg1.o: In function `main':
eg1.c:(.text+0x5): undefined reference to `hw'
collect2: error: ld returned 1 exit status

Le même résultat si vous compilez et liez en une seule étape, comme:

$ gcc -o eg1 -I. -L. -lmy_lib eg1.c
/tmp/ccQk1tvs.o: In function `main':
eg1.c:(.text+0x5): undefined reference to `hw'
collect2: error: ld returned 1 exit status

Un exemple minimal impliquant un système partagé de la bibliothèque, la bibliothèque de compression libz

eg2.c

#include <zlib.h>
#include <stdio.h>

int main()
{
    printf("%s\n",zlibVersion());
    return 0;
}

Compiler votre programme:

$ gcc -c -o eg2.o eg2.c

Essayer de lier votre programme avec libz et de l'échec:

$ gcc -o eg2 -lz eg2.o 
eg2.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
collect2: error: ld returned 1 exit status

Même si vous compilez et liez en une seule fois:

$ gcc -o eg2 -I. -lz eg2.c
/tmp/ccxCiGn7.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
collect2: error: ld returned 1 exit status

Et une variante de l'exemple 2, impliquant pkg-config:

$ gcc -o eg2 $(pkg-config --libs zlib) eg2.o 
eg2.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'

Ce que tu fais de mal?

Dans la séquence de fichiers et bibliothèques d'objets que vous souhaitez lier à faire de votre
programme, vous placez les bibliothèques avant que l'objet des fichiers qui font référence à
. Vous devez placer les bibliothèques après les fichiers objets qui font référence
pour eux.

Lien de l'exemple 1 correctement:

$ gcc -o eg1 eg1.o -L. -lmy_lib

Succès:

$ ./eg1 
Hello World

Lien exemple 2 correctement:

$ gcc -o eg2 eg2.o -lz

Succès:

$ ./eg2 
1.2.8

Lien de l'exemple 2 pkg-config variation correctement:

$ gcc -o eg2 eg2.o $(pkg-config --libs zlib) 
$ ./eg2
1.2.8

L'explication

Lecture est facultative à partir d'ici sur.

Par défaut, un lien de commande généré par GCC, sur votre distribution,
consomme les fichiers dans le lien de gauche à droite dans
ligne de commande de la séquence. Quand il constate qu'un fichier se réfère à quelque chose
et ne contient pas une définition pour elle, à la recherche d'une définition
dans les fichiers vers la droite. Si elle a finalement trouve une définition, la
de référence est résolu. Si toutes les références restent en suspens à la fin,
la liaison échoue: l'éditeur de liens ne recherche pas en arrière.

D'abord, exemple 1, avec bibliothèque statique my_lib.a

Une bibliothèque statique est indexé archive de fichiers de l'objet. Lorsque l'éditeur de liens
trouve -lmy_lib dans le lien de la séquence et en déduit qu'il s'agit
à la bibliothèque statique ./libmy_lib.a, il veut savoir si votre programme
besoin de fichiers de l'objet dans libmy_lib.a.

Il est seul fichier objet dans libmy_lib.a, à savoir my_lib.o, et il n'y a qu'une chose définie
dans my_lib.o, à savoir la fonction hw.

L'éditeur de liens décider que votre programme a besoin d' my_lib.o si et seulement si elle le sait déjà
votre programme se réfère à hw, dans un ou plusieurs des fichiers de l'objet qu'il a déjà
ajouté au programme, et qu'aucun des fichiers de l'objet qu'il a déjà ajouté
contient une définition pour hw.

Si cela est vrai, alors l'éditeur de liens extraire une copie de my_lib.o de la bibliothèque et
ajouter à votre programme. Ensuite, votre programme contient une définition pour hw, de sorte
ses références à hw sont résolu.

Lorsque vous essayez de lier le programme comme:

$ gcc -o eg1 -L. -lmy_lib eg1.o

l'éditeur de liens n'a pas encore ajouté eg1.o pour le programme quand il la voit
-lmy_lib. Parce que à ce moment, il n'a pas vu eg1.o.
Votre programme n'a pas encore fait aucune référence à des hw: il
n'a pas encore fait aucune référence à tous les, parce que toutes les références qu'il fait
sont dans eg1.o.

De sorte que le linker ne pas ajouter my_lib.o pour le programme et n'a plus de
utiliser pour libmy_lib.a.

Prochaine, il trouve eg1.o, et l'ajoute à être programme. Un fichier de l'objet dans le
lien de la séquence est toujours ajouté au programme. Maintenant, le programme rend
une référence à hw, et ne contient pas de définition de hw; mais
il n'y a plus rien dans le lien de la séquence qui pourrait fournir le manque
définition. La référence à hw finit en suspens, et le couplage échoue.

Deuxième, exemple 2, avec la bibliothèque partagée libz

Une bibliothèque partagée n'est pas une archive de fichiers de l'objet ou quelque chose comme ça. C'est
beaucoup plus comme un programme qui n'ont pas de main fonction et
au lieu de cela les expose à de multiples autres symboles qu'il définit, de sorte que les autres
les programmes peuvent utiliser lors de l'exécution.

Beaucoup de distributions Linux aujourd'hui configurer leur GCC de la chaîne de sorte que ses pilotes de langage (gcc,g++,gfortran etc)
demandez au système de l'éditeur de liens (ld) pour lier les bibliothèques partagées sur un besoin base.
Vous en avez un de ces distributions.

Cela signifie que lorsque l'éditeur de liens recherche -lz dans le lien de la séquence, et en déduit qu'il s'agit
à la bibliothèque partagée (dire) /usr/lib/x86_64-linux-gnu/libz.so, il veut savoir si toutes les références qu'il a ajoutée à votre programme qui ne sont pas encore définis, des définitions qui sont exportés par libz

Si cela est vrai, alors l'éditeur de liens pas copier les morceaux de libz et
les ajouter à votre programme; au lieu de cela, il suffit de médecin le code de votre programme
de sorte que:-

• Au moment de l'exécution, le programme de système de chargeur pour charger une copie de libz dans le
  même processus que votre programme quand il charge une copie de votre programme pour l'exécuter.

• Au moment de l'exécution, toutes les fois que votre programme se réfère à quelque chose qui est défini dans
  libz, que la référence utilise la définition exportées par la copie de libz dans
  le même processus.

Votre programme veut se référer à une seule chose qui a une définition exportées par libz,
à savoir la fonction zlibVersion, qui est mentionné qu'une seule fois, dans eg2.c.
Si l'éditeur de liens ajoute que la référence de votre programme, puis trouve la définition
exportées par libz, la référence est résolu

Mais lorsque vous essayez de lier le programme comme:

gcc -o eg2 -lz eg2.o

l'ordre des événements est mauvais tout simplement de la même façon que l'exemple 1.
Au moment de l'éditeur de liens recherche -lz, il y a pas références à rien
au programme: ils sont tous dans eg2.o, qui n'a pas encore été vu. De sorte que le
l'éditeur de liens décide qu'il n'a pas utiliser pour libz. Lorsqu'il atteint eg2.o, il ajoute à ce programme,
et puis a undefined reference to zlibVersion, le lien entre la séquence est terminée;
cette référence est en suspens, et le couplage échoue.

Enfin, la pkg-config variation de l'exemple 2 a maintenant une explication évidente.
Après shell-extension:

gcc -o eg2 $(pkg-config --libs zlib) eg2.o

devient:

gcc -o eg2 -lz eg2.o

qui est juste à l'exemple 2 à nouveau.

Je peux reproduire le problème dans l'exemple 1, mais pas dans l'exemple 2

Le lien:

gcc -o eg2 -lz eg2.o

fonctionne correctement pour vous!

(Ou: ce lien a bien fonctionné pour vous, dites, Fedora 23, mais échoue sur Ubuntu 16.04)

C'est parce que la distrib sur lequel le lien fonctionne est l'un de ceux qui
ne pas configurer son GCC de la chaîne de lien bibliothèques partagées besoin.

Retour dans la journée, il était normal pour les systèmes de type unix de lien statique et partagé
les bibliothèques par des règles différentes. Les bibliothèques statiques dans un lien de séquence ont été liés
sur le besoin base expliqué dans l'exemple 1, mais les bibliothèques partagées sont liées de manière inconditionnelle.

Ce comportement est économique à linktime parce que l'éditeur de liens n'ont pas à réfléchir
si une bibliothèque partagée est requis par le programme: si c'est une librairie partagée,
un lien. Et la plupart des bibliothèques dans la plupart des liens sont des bibliothèques partagées. Mais il ya des inconvénients aussi:-

• Il n'est pas rentable à runtime, car il peut causer des bibliothèques partagées pour être
  chargé avec un programme, même si n'a pas besoin d'eux.

• Les différentes règles d'assemblage pour les bibliothèques statiques et partagées peut être source de confusion
  à inexpert programmeurs, qui ne peut pas savoir si -lfoo dans leur lien
  va le résoudre à /some/where/libfoo.a ou à /some/where/libfoo.so,
  et pourrait ne pas comprendre la différence entre partagés et les bibliothèques statiques
  de toute façon.

Ce compromis a conduit à la situation schismatique aujourd'hui. Certaines distributions ont
changé leur GCC règles d'assemblage pour les bibliothèques partagées, de sorte que le besoin
principe s'applique pour toutes les bibliothèques. Certaines distributions ont coincé avec le vieux
.

Pourquoi j'obtiens toujours ce problème, même si je compile-et-link en même temps?

Si je ne l':

$ gcc -o eg1 -I. -L. -lmy_lib eg1.c

sûrement gcc a pour compiler eg1.c d'abord, et ensuite le lien qui en résulte
fichier objet avec libmy_lib.a. Alors, comment peut-il ne pas savoir que le fichier objet
est nécessaire quand il fait le lien?

Parce que la compilation et la liaison avec une seule commande ne change pas le
l'ordre de l'articulation de la séquence.

Lorsque vous exécutez la commande ci-dessus, gcc chiffres que vous voulez compilation +
de liaison. Donc, en coulisses, il génère une compilation de commande, et s'exécute
c', puis génère un lien de commande, et l'exécute, comme si vous avait couru le
deux commandes:

$ gcc -I. -c -o eg1.o eg1.c
$ gcc -o eg1 -L. -lmy_lib eg1.o

De sorte que le couplage échoue juste comme il le fait si vous ne exécuter les deux commandes. L'
seule différence que l'on remarque dans l'échec est que gcc a généré un
temporaire de fichier de l'objet dans la compilation + lien de cas, parce que vous n'êtes pas la raconter
pour utiliser eg1.o. Nous le voyons:

/tmp/ccQk1tvs.o: In function `main'

au lieu de:

eg1.o: In function `main':

Voir aussi

L'ordre dans lequel interdépendants liés bibliothèques sont spécifié est incorrect

Mettre interdépendants les bibliothèques dans le mauvais ordre est juste une façon
dans lequel vous pouvez obtenir les fichiers qui besoin définitions de choses à venir
plus tard dans la liaison que les fichiers qui fournir les définitions. Mettre les bibliothèques avant le
les fichiers objets qui parlent d'eux est une autre façon de faire la même erreur.

OriginalL'auteur Mike Kinghan

Lors de vos chemins d'accès sont différents

De l'éditeur de liens erreurs peuvent se produire lorsqu'un fichier d'en-tête et de ses associés de la bibliothèque partagée (.fichier lib) sortir de la synchronisation. Laissez-moi vous expliquer.

Comment les lieurs de travail? L'éditeur de liens correspond à une déclaration de fonction (déclarée dans l'en-tête) avec sa définition (dans la bibliothèque partagée) en comparant leurs signatures. Vous pouvez obtenir une erreur de l'éditeur de liens si le linker ne trouve pas de définition de la fonction qui correspond parfaitement.

Est-il possible de toujours obtenir un linker erreur, même si la déclaration et la définition semblent correspondre? Oui! Ils peuvent regarder la même chose dans le code source, mais cela dépend vraiment de ce que le compilateur voit. Essentiellement, vous pourriez vous retrouver avec une situation comme celle-ci:

//header1.h
typedef int Number;
void foo(Number);

//header2.h
typedef float Number;
void foo(Number); //this only looks the same lexically

Remarquez comment même si les déclarations de fonction identique dans le code source, mais ils sont vraiment différents selon le compilateur.

Vous pourriez vous demander comment on se retrouve dans une situation comme ça? Chemins à inclure bien sûr! Si lors de la compilation de la bibliothèque partagée, le chemin mène à header1.h et vous vous retrouvez à l'aide de header2.h dans votre propre programme, vous serez laissés gratter la tête se demandant ce qui s'est passé (pun intended).

Un exemple de comment cela peut se produire dans le monde réel est expliqué ci-dessous.

La poursuite de l'élaboration d'un exemple

J'ai deux projets: graphics.lib et main.exe. Les deux projets dépendent de common_math.h. Supposons que la bibliothèque exportations de la fonction suivante:

//graphics.lib    
#include "common_math.h" 

void draw(vec3 p) { ... } //vec3 comes from common_math.h

Et puis vous aller de l'avant et inclure la librairie dans votre propre projet.

//main.exe
#include "other/common_math.h"
#include "graphics.h"

int main() {
    draw(...);
}

Boom! Vous obtenez une erreur de l'éditeur de liens et vous n'avez aucune idée de pourquoi ça ne fonctionne pas. La raison en est que la bibliothèque commune utilise des versions différentes de la même inclure common_math.h (j'en ai fait évident ici dans l'exemple, y compris par un chemin différent, mais il n'est pas toujours si évident. Peut-être que le chemin est différent dans les paramètres du compilateur).

Remarque dans cet exemple, l'éditeur de liens vous dira qu'il ne pouvait pas trouver draw(), alors qu'en réalité, vous savez, c'est évidemment d'être exportées par la bibliothèque. Vous pourriez passer des heures à vous gratter la tête en se demandant ce qui n'allait pas. Le truc, c'est que l'éditeur de liens voit une signature différente parce que les types de paramètres sont légèrement différentes. Dans l'exemple, vec3 est d'un type différent dans les deux projets, aussi loin que le compilateur est concerné. Cela peut se produire parce qu'ils viennent de deux légèrement différentes inclure des fichiers (peut-être les fichiers d'en venir à partir de deux versions différentes de la bibliothèque).

Débogage de l'éditeur de liens

DUMPBIN est votre ami, si vous utilisez Visual Studio. Je suis sûr que d'autres compilateurs ont d'autres outils similaires.

Le processus qui va comme ceci:

1. Remarque l'étrange déformation nom donné dans l'éditeur de liens d'erreur. (eg. dessiner@graphiques@XYZ).
2. Vider les symboles exportés à partir de la bibliothèque dans un fichier texte.
3. De recherche pour les symboles exportés d'intérêt, et de l'avis que la déformation d'un nom différent.
4. Attention sur le pourquoi de la déformation des noms terminés en place différents. Vous serez en mesure de voir que les types de paramètres sont différents, même si ils ont le même aspect dans le code source.
5. Raison pour laquelle ils sont différents. Dans l'exemple donné ci-dessus, ils sont différents en raison de différents fichiers à inclure.

[1] Par le projet, je veux dire un ensemble de fichiers sources qui sont liés ensemble pour produire une bibliothèque ou d'un fichier exécutable.

EDIT 1: Réécriture de la première section d'être plus facile à comprendre. S'il vous plaît commentaire ci-dessous pour laissez-moi savoir si quelque chose doit être corrigé. Merci!

OriginalL'auteur fafaro

Manquant "extern" dans const déclarations de variables/définitions (C++ seulement)

Pour les personnes venant de C, il serait peut-être une surprise qu'en C++ mondiale constvariables internes (ou statique) de liaison. En C, ce n'était pas le cas, toutes les variables globales sont implicitement extern (c'est à dire lorsque la static mot-clé est manquante).

Exemple:

//file1.cpp
const int test = 5;    //in C++ same as "static const int test = 5"
int test2 = 5;

//file2.cpp
extern const int test;
extern int test2;

void foo()
{
 int x = test;   //linker error in C++ , no error in C
 int y = test2;  //no problem
}

correcte serait d'utiliser un fichier d'en-tête et de les inclure dans file2.cpp et file1.cpp

extern const int test;
extern int test2;

Sinon on pourrait déclarer la const variable dans file1.cpp explicite extern

OriginalL'auteur Andreas H.

Lors de la liaison à l'encontre de bibliothèques partagées, assurez-vous que les symboles utilisés ne sont pas cachés.

Le comportement par défaut de gcc est que tous les symboles sont visibles. Toutefois, lorsque les unités de traduction sont construits avec l'option -fvisibility=hidden, seules les fonctions/symboles marqués avec __attribute__ ((visibility ("default"))) sont externes dans le résultat de l'objet partagé.

Vous pouvez vérifier si les symboles que vous cherchez sont à l'extérieur par l'invocation:

# -D shows (global) dynamic symbols that can be used from the outside of XXX.so
nm -D XXX.so | grep MY_SYMBOL 

le caché/local symboles sont affichés par nm avec des minuscules type de symbole, par exemple t au lieu de " T pour le code-section:

nm XXX.so
00000000000005a7 t HIDDEN_SYMBOL
00000000000005f8 T VISIBLE_SYMBOL

Vous pouvez également utiliser nm avec l'option -C à demangle les noms (si C++ a été utilisé).

Similaire à Windows dll, on marque des fonctions publiques avec une définissent, par exemple DLL_PUBLIC défini comme:

#define DLL_PUBLIC __attribute__ ((visibility ("default")))

DLL_PUBLIC int my_public_function(){
  ...
}

Qui correspond à peu près à Windows/MSVC-version:

#ifdef BUILDING_DLL
    #define DLL_PUBLIC __declspec(dllexport) 
#else
    #define DLL_PUBLIC __declspec(dllimport) 
#endif

Plus informations sur la visibilité peuvent être trouvés sur le gcc wiki.

---

Lorsqu'une unité de traduction est compilé avec -fvisibility=hidden l'résultant symboles ont toujours une liaison externe (illustré par une majuscule type de symbole par nm) et peut être utilisé pour une liaison externe sans problème si des fichiers de l'objet de devenir une partie d'une des bibliothèques statiques. Le lien devient locale uniquement lorsque l'objet les fichiers liés dans une bibliothèque partagée.

De trouver des symboles dans des fichiers objets sont cachés exécuter:

>>> objdump -t XXXX.o | grep hidden
0000000000000000 g     F .text  000000000000000b .hidden HIDDEN_SYMBOL1
000000000000000b g     F .text  000000000000000b .hidden HIDDEN_SYMBOL2

OriginalL'auteur ead