Vinculador ferramentas erro LNK2019

Mensagem de erro

símbolo externo não resolvido 'símbolo' referenciado na função 'function'

Um símbolo indefinido externo (symbol) foi encontrado em function. Para resolver esse erro, forneça uma definição de símbolo ou remover o código que faz referência a ele.Para obter mais informações, consulte,

O exemplo a seguir gera LNK2019:

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

LNK2019 também pode ocorrer quando você declara, mas não define um membro de dados estático.O exemplo a seguir gera LNK2019:

// 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;
}

Considere o exemplo a seguir:

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

If i e g não são definidos em um dos arquivos incluídos na compilação, o vinculador vai gerar LNK2019. Essas definições podem ser adicionadas, incluindo o arquivo de código fonte que contém sistema autônomo definições sistema autônomo parte da compilação.Como alternativa, você pode passar .obj ou .lib arquivos que contêm as definições para o vinculador.

Para projetos do C++ das versões anteriores que foram atualizados para a versão corrente, se __UNICODE foi definido e o ponto de entrada foi WinMain, você precisará alterar o nome da função de ponto de entrada para _tWinMain ou wWinMain.

Problemas comuns que causam LNK2019 incluem:

  • A declaração do símbolo contém um erro de ortografia, de modo que ele não seja o mesmo nome que a definição do símbolo.

  • Uma função foi usada, mas o tipo ou o número de parâmetros não correspondeu à definição de função.

  • A convenção de chamada (__cdecl, __stdcall, or __fastcall) é diferente no uso de declaração da função e a definição de função.

  • Definições de símbolo em um arquivo que foi compilado sistema autônomo um programa em C e símbolos são declarados em um arquivo do C++ sem um modificador de extern "C".Nesse caso, modifique a declaração, por exemplo, em vez de:

    extern int i;
extern void g();

    use:

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

    Da mesma forma, se você definir um símbolo em um arquivo de C++ que será usado por um programa em C, usar extern "C" na definição.

  • Um símbolo é definido sistema autônomo estático e referenciado mais tarde fora do arquivo.No C++, ao contrário de C, constantes global have static ligação. Para contornar essa limitação, você pode incluir o const inicializações em um cabeçalho de arquivo e inclua esse cabeçalho nos arquivos .cpp ou você pode tornar a variável não constante e usar uma referência constante para acessá-lo.

  • Um membro estático de uma classe não está definido.Por exemplo, membro variável si na classe declaração abaixo deve ser definida separadamente:

    // 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
}

O exemplo a seguir gera LNK2019 em um operador definido pelo usuário.

// 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
}

The / VERBOSEopção de vinculador ajudará você a ver quais arquivos o vinculador faz referência.The / EXPORTAÇÕES and / SÍMBOLOS opções do utilitário DUMPBIN também podem ajudar você ver quais símbolos são definidos nos arquivos dll e/biblioteca de objetos.

Base de Dados de Conhecimento Microsoft da Microsoft tem mais informações sobre LNK2019; consulte http://suporte.Microsoft.com.

LNK2019 também pode ser gerado sistema autônomo resultado do trabalho de conformidade que foi concluído para o Visual Studio .NET 2003: modelo de amigos e a especialização.No Visual Studio .NET 2003, uma declaração de uma função amigo com o mesmo nome de um modelo de função não faz referência a esse modelo de função a menos que explicitamente sistema autônomo argumentos de modelo são especificados na declaração do amigo.

Se você não especificar argumentos de modelo, a declaração de amigo declara uma função do modelo não.

See Resumo das alterações de quebras de time de compilar para obter mais informações.

Para obter um código que é válido nas versões do Visual Studio .NET 2003 e o Visual Studio .NET do Visual C++, especifica explicitamente a lista de argumentos da função amigo modelo.

// 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 também pode ocorrer sistema autônomo resultado do trabalho de conformidade que foi concluído em Visual C++ 2005, /Zc:wchar_t Agora é ativada por padrão. Todos os módulos não podem ter sido compilados com o mesmo /Zc:wchar_t configurações, fazendo com que digite referências não resolver para tipos compatível. Para resolver, garantir que os tipos em todos os módulos sejam compatível, tanto por compilando com o apropriado /Zc:wchar_t configurações (por exemplo, usando /Zc:wchar_t- durante a criação de módulos com o Visual C++ 2005 conjunto de ferramentas que será vinculado com módulos de versões anteriores) ou, se possível, atualizando seus tipos para que sejam compatível.

Referências explícitas para comsupp.lib, a partir do pragma comentário ou por meio da linha de comando devem ser alteradas para usar agora comsuppw.lib ou comsuppwd.lib, sistema autônomo /Zc:wchar_t Agora é ativada por padrão. comsupp.lib ainda deve ser usada quando compilando com /Zc:wchar_t-.

Para obter mais informações, consulte Quebrar alterações no compilador de 2005 Visual C++ e /Zc:wchar_t (wchar_t é tipo nativo).

O exemplo a seguir cria uma exportar usa WCHAR, que resolve para wchar_t.

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

O exemplo a seguir gera LNK2019:

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

int main() {
   func(0);
}

Para resolver esse erro, altere unsigned short wchar_t ou WCHAR ou compilar LNK2019g.cpp com /Zc:wchar_t-.

Você também pode obter LNK2019 se você estiver criando um aplicativo de console com /SUBSYSTEM:WINDOWS. O símbolo não resolvido será _WinMain@16.Nesse caso, basta vincular com /SUBSYSTEM:CONSOLE.

  • Last updated on