Erro das Ferramentas de Vinculador LNK2001

símbolo externo não resolvido “símbolo”

O código referencia algo (como uma função, uma variável, ou um rótulo) que o vinculador não pode localizar em bibliotecas e em arquivos de objeto.

Essa mensagem de erro é seguida pelo erro fatal LNK1120.

Causas possíveis

• Ao atualizar um projeto gerenciado de biblioteca ou do serviço Web do Visual C++ 2003, a opção de compilador de /Zl é adicionada à página de propriedades de Linha de Comando . Isso fará LNK2001.

  Para resolver este erro, um ou outro adicionar msvcrt.lib e msvcmrt.lib a propriedade adicional de dependências do vinculador. Ou, remova /Zl da página de propriedades de Linha de Comando . Para obter mais informações, consulte /Zl (omitir nome da biblioteca padrão) e Como abrir páginas de propriedade do projeto.

• O código que o solicita não existir (o símbolo foi digitado incorretamente ou usa os casos errados, por exemplo).

• O código solicita a coisa errada (você estiver usando versões mistas bibliotecas, algumas de uma versão do produto, outro de outra versão).

Causas específicas

Problemas de código

• Se o texto LNK2001 diagnóstico informa que __check_commonlanguageruntime_version é um símbolo externo não resolvido, consulte LNK2019 para obter informações sobre como resolver.

• A definição do modelo do membro está fora da classe. Visual C++ tiver uma restrição na qual os modelos de membro completamente devem ser definidos dentro da classe inclusive. Consulte o artigo da base de dados Q239436 para obter mais informações sobre como LNK2001 e de modelos do membro.

• As caixas incompatíveis em seu arquivo de código ou do definição (.def) podem causar LNK2001. Por exemplo, se você denominada var1 variável em um arquivo de origem C++ e o tentou o acessar como VAR1 em outro.

• Um projeto que usa o entanto função que inlining define as funções em um arquivo .cpp em vez de no arquivo de cabeçalho pode causar LNK2001.

• A função c da chamada de um programa C/C++ criando sem usar extern C “2.0” (que faz com que o compilador use a convenção de nomenclatura C) pode causar LNK2001. As opções /Tp e /Tc do compilador fazem com que o compilador cria arquivos como C ou C++ 2.0, respectivamente, independentemente da extensão de nome de arquivo. Essas opções podem fazer com que os nomes de função diferentes do que você espera.

• Tentar referenciar as funções ou os dados que não têm vinculação externo pode causar LNK2001. Em C++, as funções embutidas e os dados de const têm vinculação interno a menos que especificado explicitamente como extern.

• corpo ausente ou variável de função pode causar LNK2001. Apenas com um protótipo da função ou declaração de extern o compilador pode continuar sem erro, mas o vinculador não pode resolver uma chamada para um endereço ou uma referência a uma variável porque não há nenhum código de função ou variável espaço reservado.

• Chamar uma função com tipos de parâmetro que não correspondem aos da declaração de função pode causar LNK2001. Decoração de nome insere os parâmetros de função no nome da função decorado final.

• Os protótipos incorretamente incluídos, que fazem com que o compilador espera um corpo de função que não é fornecido podem causar LNK2001. Se você tiver uma classe e a implementação da classe não de uma função F, ter cuidado com as regras de escopo- resolução C++.

• Quando usar C++, incluindo um protótipo da função em uma definição de classe e falhar a inclui a implementação da função para essa classe pode causar LNK2001.

• Tentar chamar uma função virtual pura do construtor de destruidor ou de uma classe base abstrata pode causar LNK2001. Uma função virtual pure não tem nenhuma implementação da classe base.

• Tentar usar uma variável declarada em uma função ()uma variável localfora do escopo dessa função poderá causar LNK2001.

• Ao criar uma versão lançada de um projeto de ATL, indica que o código de inicialização de CRT será necessário. Para corrigir, siga um destes procedimentos,

  • Remover _ATL_MIN_CRT da lista de pré-processador define para permitir que o código de inicialização de CRT serão incluídos. Consulte Página de propriedades geral dos parâmetros de configuração para obter mais informações.

  • Se for possível, remova as chamadas a funções de CRT que exigem o código de inicialização de CRT. Em vez disso, use seus equivalentes do Win32. Por exemplo, use lstrcmp em vez de strcmp. As funções conhecidas que exigem o código de inicialização de CRT são algumas funções de cadeia de caracteres e de ponto flutuante.

Criando e vinculando problemas

• O projeto está faltando uma referência a uma biblioteca (.LIB) ou arquivo de objeto (.OBJ). Consulte arquivos de .lib como a entrada do vinculador para obter mais informações.

• Se você usar /NODEFAULTLIB ou /Zl, as bibliotecas que contêm o código exigido não serão vinculadas no projeto a menos que você os inclua explicitamente. (Ao compilar com /clr ou /clr:pure, você verá uma referência a .cctor; consulte Inicialização de assemblies mistos para obter mais informações.)

• Se você estiver usando o Unicode e MFC, você obterá um externo não resolvido em _WinMain@16 se você não criar um entrypoint a wWinMainCRTStartup; use /ENTRY. Consulte Unicode que o programa resumo.

  Consulte os seguintes artigos da Base de Dados de Conhecimento, localizados na MSDN library, para obter mais informações. Na MSDN library, clique na guia de Pesquisar , cole o número de artigo ou o título do artigo na caixa de texto, e clique em Listar Tópicos. Se você pesquisa no número de artigo, verifique se a opção de Pesquisar apenas os títulos é clara.

  • Q125750 “PRB: Erro LNK2001: “_WinMain@16”: Símbolo externo não resolvido”

  • Q131204 “PRB: A seleção de projeto errada causa LNK2001 em _WinMain@16”

  • Suporte de Q100639 Unicode “na biblioteca de classes do Microsoft”

  • Q291952 “PRB: Erro LNK2001 de link: _main Não resolvido do símbolo externa”

• Vincular o código compilado com /MT na biblioteca LIBC.lib causa LNK2001 em _beginthread, em _beginthreadex, em _endthreade, em _endthreadex.

• Vincular o código que exige as bibliotecas de vários threads (MFC qualquer codificação ou codifica compilado com /MT) faz com LNK2001 em _beginthread, em _beginthreadex, em _endthreade, em _endthreadex. Consulte o seguinte artigo da Base de Dados de Conhecimento para obter mais informações:

  • Q126646 “PRB: A mensagem de erro: LNK2001 em __beginthreadex e no __endthreadex”

  • “INFO Q128641: Opções do compilador do /Mx e o LIBC, LIBCMT, liberais de MSVCRT”

  • Q166504 “PRB: MFC O e o CRT devem corresponder na depuração/versão e em estático e dinâmico” em

• Ao criar com /MD, uma referência a “funcional” na origem se torna uma referência “__imp__func” no objeto desde que todo o tempo de execução é mantido agora dentro de uma DLL. Se você tentar vincular às bibliotecas estáticas LIBC.lib ou LIBCMT.lib, você obterá LNK2001 em __imp__func. Se você tentar vincular a MSVCxx.lib ao construir sem /MD você não será sempre LNK2001, mas você provavelmente terá outros problemas.

• Vincular com as bibliotecas do modo de versão ao criar uma versão de depuração de um aplicativo pode causar LNK2001. De maneira semelhante, usar uma opção de /Mxd (/MTd, ou /MDd) e/ou definir _DEBUG e vinculá-lo com as bibliotecas de versão externals não serão resolvidos entre outros problemas potenciais (). Vincular uma compilação do modo de versão com as bibliotecas de depuração também causar problemas semelhantes.

• As versões de combinação de bibliotecas da Microsoft e de produtos do compilador podem ser problemáticas. As novas bibliotecas de uma versão do compilador podem conter os novos símbolos que não podem ser encontrados em bibliotecas incluídas com versões anteriores. Talvez você queira alterar a ordem dos diretórios no caminho de pesquisa, ou em alterá-los apontar para a versão atual.

  As ferramentas | Opções | Projetos | A caixa de diálogo os diretórios de VC++, na seleção dos arquivos de biblioteca, permite que você altere a ordem de pesquisa. A pasta do vinculador na caixa de diálogo páginas de propriedades do projeto também pode conter os caminhos que poderiam ser expirado.

  Esse problema pode aparecer a nova SDK está instalado (talvez a um local diferente), e a ordem da pesquisa não é atualizado para apontar para o novo local. Normalmente, você deverá colocar o caminho a nova SDKs inclui e diretórios de biblioteca em frente do local padrão do Visual C++. Além disso, um projeto que contém caminhos inseridos ainda pode apontar para caminhos antigos que não são válidas, mas expirado para a nova funcionalidade adicionada pela nova versão instalada em um local diferente.

• Não há nenhum padrão para Nomeação C++ entre fornecedores do compilador ou mesmo entre versões diferentes de um compilador. Consequentemente, vincular os arquivos de objeto compilados com outros compiladores não pode gerar o mesmo esquema de nomeação e assim causar o erro LNK2001.

• Misturar embutido e não embutida cria opções em módulos diferentes pode causar LNK2001. Se a biblioteca criando c é criada com a função que inlining (/Ob1 ativado ou /Ob2) mas o arquivo de cabeçalho correspondente que descreve as funções tem inlining desativado (sem a palavra-chave de inline ), você obterá o erro. Para evitar esse problema, tem as funções embutidas definidas com inline no arquivo de cabeçalho que você vai incluir em outros.

• Se você estiver usando a diretiva do compilador de #pragma inline_depth , certifique-se de ter valor de 2 ou maior conjunto, e verifique se você está usando a opção de compilador de /Ob1 ou de /Ob2 .

• Omitindo a opção /NOENTRY de LINK quando criar uma DLL de recurso somente fará LNK2001.

• Usar /SUBSYSTEM incorreto ou configurações de /ENTRY pode causar LNK2001. Por exemplo, se você escrever um aplicativo baseado em caractere (um aplicativo de console) e especifica /SUBSYSTEM:WINDOWS, você obterá um externo não resolvido para WinMain. Para obter mais informações sobre esses padrões e pontos de entrada, consulte as opções do vinculador de /SUBSYSTEM e de /ENTRY .

Exportar problemas

• Quando você está movendo um aplicativo de 16 a 32 ou 64 bits, LNK2001 poderá ocorrer. A sintaxe atual do arquivo de definição (.def) requer que __cdecl, __stdcall, e as funções de __fastcall são listados na seção EXPORTS sem sublinhados (undecorated). Isso difere da sintaxe de 16 bits, onde devem ser listados por sublinhados (decorados). Para obter mais informações, consulte a descrição da seção de EXPORTAÇÕES do arquivo de definição.

• Alguns exportação listado no arquivo .def e não seja localizado) causará LNK2001. Talvez isso ocorra porque não existe, é escrito incorretamente, ou usa nomes (C++ decoraram os arquivos de .def não possuem nomes decorados)

Interpretando as saídas

Quando um símbolo é resolvido, não é possível obter informações sobre a função por seguintes diretrizes:

Nas plataformas x86, na decoração de convenção de chamada para os nomes criados em C, ou para nomes de extern C “2.0” em C++, é:

• __cdecl
  A função tem um prefixo de sublinhado (_).

• __stdcall
  A função tem um prefixo de sublinhado (_) e @ um sufixo seguido pelo tamanho alinhado DWORD dos parâmetros na pilha.

• __fastcall
  A função tem um prefixo @ @ e um sufixo seguido pelo tamanho alinhado DWORD dos parâmetros na pilha.

Use undname.exe para obter o formulário undecorated de um nome decorado.

Para obter mais informações sobre algumas das causas listadas acima, consulte Nomeie a decoração.