Freigeben über

Linkertoolfehler LNK2019

  • Artikel

Verweis auf nicht aufgelöstes externes Symbol 'Symbol' in Funktion 'Funktion'

In function wurde ein nicht definiertes externes Symbol (symbol) gefunden. Um diesen Fehler zu beheben, geben Sie eine Definition für symbol an, oder entfernen Sie den Code, der darauf verweist. Weitere Informationen finden Sie in den folgenden Dokumenten:

Im folgenden Beispiel wird LNK2019 generiert.

// LNK2019.cpp
// LNK2019 expected
extern char B[100];   // B is not available to the linker
int main() {
   B[0] = ' ';
}

LNK2019 kann auch auftreten, wenn ein statischer Datenmember deklariert, aber nicht definiert wird. Im folgenden Beispiel wird LNK2019 generiert.

// LNK2019b.cpp
// LNK2019 expected
struct C {
   static int s;
};

// Uncomment the following line to resolve.
// int C::s;

int main() {
   C c;
   C::s = 1;
}

Betrachten Sie das folgende Beispiel.

// LNK2019c.cpp
// LNK2019 expected
extern int i;
extern void g();
void f() {
   i++;
   g();
}
int main() {}

Wenn i und g nicht in einer der Builddateien definiert sind, generiert der Linker den Fehler LNK2019. Sie können diese Definitionen hinzufügen, indem Sie die Quellcodedatei, die die Definitionen enthält, als Teil der Kompilierung einlesen. Alternativ können Sie OBJ- oder LIB-Dateien, die die Definitionen enthalten, an den Linker übergeben.

Wenn bei C++-Projekten, die in früheren Versionen erstellt und auf die aktuelle Version aktualisiert wurden, __UNICODE definiert wurde und der Einstiegspunkt "WinMain" war, müssen Sie den Namen der Einstiegspunktfunktion in "_tWinMain" oder "wWinMain" ändern.

LNK2019 kann durch die folgenden allgemeinen Probleme verursacht werden:

  • Für die Deklaration des Symbols wird nicht die gleiche Schreibweise verwendet wie für die Definition des Symbols.

  • Eine Funktion wurde zwar verwendet, der Typ oder die Anzahl ihrer Parameter stimmen jedoch nicht mit der Funktionsdefinition überein.

  • Buildabhängigkeit wird nur als Projektabhängigkeit in der Projektmappe definiert. In früheren Versionen von Visual Studio war diese Ebene der Abhängigkeit ausreichend. Ab Visual Studio 2010 erfordert Visual Studio jedoch einen Interprojektverweis. Wenn das Projekt keinen Interprojektverweis enthält, wird dieser Linkerfehler möglicherweise angezeigt.

  • Die Aufrufkonvention (__cdecl __stdcall oder __fastcall) weist Unterschiede zur Verwendung der Funktionsdeklaration und -definition auf.

  • Die Symboldefinitionen sind in einer Datei enthalten, die als C-Programm kompiliert wurde, die Symbole wurden jedoch in einer C++-Datei ohne extern "C"-Modifizierer deklariert. Wenn dies der Fall ist, ändern Sie die Deklaration. Verwenden Sie z. B. anstelle von

    extern int i;
extern void g();

    use

    extern "C" int i;
extern "C" void g();

    Auch wenn ein Symbol in einer C++-Datei definiert wird, die von einem C-Programm verwendet wird, geben Sie extern "C" in der Definition an.

  • Ein Symbol wird als static definiert, später wird jedoch außerhalb der Datei darauf verwiesen. In C++ haben globale Konstanten anders als in C eine static-Verknüpfung. Um diese Einschränkung zu umgehen, können Sie die const-Initialisierungen in eine Headerdatei einfügen und diesen Header anschließend in die CPP-Dateien einlesen, oder Sie deklarieren die Variable als nicht konstant und verwenden einen konstanten Verweis, um darauf zuzugreifen.

  • Ein statischer Member einer Klasse wurde nicht definiert. Die si-Membervariable in der Klassendeklaration im folgenden Beispiel sollte z. B. separat definiert werden.

    // LNK2019d.cpp
#include <stdio.h>
struct X {
   static int si;
};

// int X::si = 0;   // uncomment this line to resolve

int main() {
   X *px = new X[2];
   printf_s("\n%d",px[0].si);   // LNK2019
}

Im folgenden Beispiel wird der Fehler LNK2019 bei einem benutzerdefinierten Operator generiert.

// LNK2019e.cpp
// compile with: /EHsc
// LNK2019 expected
#include <iostream>
using namespace std;

template<class T> class 
Test {
   friend ostream& operator<<(ostream&, Test&);
   // Uncomment the following line to resolve.
   // template<typename T> friend ostream& operator << (ostream&, Test<T>&);
};

template<typename T>
ostream& operator<<(ostream& os, Test<T>& tt) {
   return os;
}

int main() {
   Test<int> t;
   cout << "Test: " << t << endl;   // unresolved external
}

Mithilfe der /VERBOSE-Linkeroption können Sie feststellen, auf welche Dateien der Linker verweist. Mit den /EXPORTS- und /SYMBOLS-Optionen des DUMPBIN-Hilfsprogramms können Sie auch herausfinden, welche Symbole in den DLL- und Objekt-/Bibliotheksdateien definiert sind.

Weitere Informationen zu LNK2019 finden Sie auf der Microsoft Support-Website (möglicherweise in englischer Sprache).

LNK2019 kann auch aufgrund einer Konformitätsverbesserung für Friend-Vorlagen und die Spezialisierung in Visual Studio .NET 2003 ausgegeben werden. In Visual Studio .NET 2003 bezieht sich die Deklaration einer Friend-Funktion mit demselben Namen wie die Funktionsvorlage nicht auf diese Funktionsvorlage, wenn in der Friend-Deklaration nicht explizit Vorlagenargumente angegeben sind.

Wenn Sie keine Vorlagenargumente angeben, deklariert die Friend-Deklaration eine nicht auf Vorlagen basierende Funktion.

In Code, der sowohl in der Visual Studio .NET 2003- als auch der Visual Studio .NET 2002-Version von Visual C++ gültig ist, geben Sie explizit die Vorlagenargumentliste der Friend-Funktion an.

// LNK2019f.cpp
// LNK2019 expected
template<class T>
void f(T) {}

template<class T>
struct S {
   friend void f(T);
   // try the folowing line instead
   // friend void f<T>(T);
};

int main() {
   S<int> s;
   f(1);   // unresolved external
}

LNK2019 kann auch aufgrund einer Konformitätsverbesserung in Visual C++ 2005 ausgegeben werden. /Zc:wchar_t ist jetzt standardmäßig aktiviert. Es wurden möglicherweise nicht alle Module mit denselben /Zc:wchar_t-Einstellungen kompiliert, sodass Typverweise nicht in kompatible Typen aufgelöst werden können. Stellen Sie sicher, dass die Typen in allen Modulen kompatibel sind, indem Sie mit den entsprechenden /Zc:wchar_t-Einstellungen kompilieren (verwenden Sie z. B. /Zc:wchar_t-, wenn Sie Module mit Visual C++-Tools erstellen, die mit Modulen aus früheren Versionen verknüpft werden) oder indem Sie nach Möglichkeit die Typen so aktualisieren, dass sie kompatibel sind.

Ändern Sie explizite Verweise auf "comsupp.lib" im Kommentarpragma oder über die Befehlszeile in "comsuppw.lib" oder "comsuppwd.lib". Dieser Schritt ist erforderlich, weil /Zc:wchar_t jetzt standardmäßig aktiviert ist. Verwenden Sie weiterhin "comsupp.lib", wenn Sie mit /Zc:wchar_t- kompilieren.

Weitere Informationen finden Sie unter /Zc:wchar_t (wchar_t ist der systemeigene Typ).

Im folgenden Beispiel wird eine Exportdatei erstellt, die WCHAR verwendet, das in wchar_t aufgelöst wird.

// LNK2019g.cpp
// compile with: /LD
#include "windows.h"
// WCHAR resolves to wchar_t
__declspec(dllexport) void func(WCHAR*) {}

Im folgenden Beispiel wird LNK2019 generiert.

// LNK2019h.cpp
// compile with: LNK2019g.lib
// LNK2019 expected
__declspec(dllimport) void func(unsigned short*);

int main() {
   func(0);
}

Um diesen Fehler zu beheben, ändern Sie unsigned short in wchar_t oder WCHAR, oder kompilieren Sie "LNK2019g.cpp" mit /Zc:wchar_t-.

LNK2019 kann auch ausgegeben werden, wenn Sie eine Konsolenanwendung unter Verwendung von /SUBSYSTEM:WINDOWS erstellen. Das nicht aufgelöste Symbol ist "_WinMain@16". In diesem Fall erstellen Sie einfach eine Verknüpfung mit /SUBSYSTEM:CONSOLE.