Error de las herramientas del vinculador LNK2019
símbolo externo 'símbolo' sin resolver al que se hace referencia en la función 'función'
Se halló un símbolo externo no definido (symbol) en function. Para resolver este error, indique una definición de symbol o quite el código que hace referencia a él. Para obtener más información, vea los documentos siguientes:
En el ejemplo siguiente, se genera el error del vinculador LNK2019.
// LNK2019.cpp
// LNK2019 expected
extern char B[100]; // B is not available to the linker
int main() {
B[0] = ' ';
}
El vinculador LNK2019 también se puede producir cuando se declara un miembro de datos estático pero no definido. En el ejemplo siguiente, se genera el error del vinculador 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;
}
Observe el siguiente ejemplo.
// LNK2019c.cpp
// LNK2019 expected
extern int i;
extern void g();
void f() {
i++;
g();
}
int main() {}
Si i y g no están definidas en uno de los archivos incluidos en la compilación, el vinculador generará el error LNK2019. Pueden agregarse estas definiciones incluyendo, como parte de la compilación, el archivo de código fuente que contiene las definiciones. Como alternativa, se pueden pasar al vinculador archivos .obj o .lib que contengan las definiciones.
En los proyectos de C++ que se han creado anteriormente en versiones anteriores y que se han actualizado a la versión actual, si se definió __UNICODE y el punto de entrada era WinMain, tendrá que cambiarse el nombre de la función del punto de entrada a _tWinMain o wWinMain.
Algunos de los problemas comunes que causan el error del vinculador LNK2019 incluyen:
La declaración del símbolo no se ha escrito igual que la definición del símbolo.
Se utilizó una función, pero el tipo o número de parámetros no coincide con la definición de la función.
La dependencia de compilación solamente se define como una dependencia del proyecto en la solución. En versiones anteriores de Visual Studio, este nivel de dependencia era suficiente. Sin embargo, a partir de Visual Studio 2010, Visual Studio requiere una referencia entre proyectos. Si el proyecto no tiene una referencia entre proyectos, se puede recibir este error del vinculador.
La convención de llamada (__cdecl, __stdcall, o __fastcall) difiere en el uso de la declaración de función y la definición de función.
Las definiciones de símbolo se encuentran en un archivo que se compiló como un programa de C, mientras que los símbolos se declaran en un archivo de C++ sin modificador extern "C". Si éste es el caso, modifique la declaración. Por ejemplo, en lugar de
extern int i; extern void g();use
extern "C" int i; extern "C" void g();Igualmente, si define un símbolo en un archivo de C++ que se usará en otro programa de C, use extern "C" en la definición.
Un símbolo está definido como static y después se hace referencia a él fuera del archivo. En C++, a diferencia de C, las constantes globales tienen vinculación static. Para resolver esta limitación, se puede incluir las inicializaciones const en un archivo de encabezado e incluirlo en los archivos .cpp, o hacer la variable no constante y utilizar una referencia constante para obtener acceso a ella.
Un miembro static de una clase no está definido. Por ejemplo, la variable miembro si de la declaración de clase en el ejemplo siguiente, debe definirse por separado.
// 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 }
El ejemplo siguiente genera el error LNK2019 en un operador definido por el usuario.
// 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
}
La opción del compilador /VERBOSE puede servir de ayuda para determinar a qué archivos hace referencia el vinculador. Las opciones /EXPORTS y /SYMBOLS de la herramienta DUMPBIN también pueden servir de ayuda para detectar qué símbolos están definidos en los archivos .dll, así como archivos objeto y de biblioteca.
Para obtener más información sobre el error del vinculador LNK2019, vea el sitio web Soporte Microsoft.
El error LNK2019 también puede producirse como resultado del trabajo de conformidad realizado para friends de plantillas y especialización de Visual Studio .NET 2003. En Visual Studio .NET 2003, una declaración de una función friend con el mismo nombre que una plantilla de función no hace referencia a esa plantilla a no ser que se hayan especificado explícitamente argumentos de plantilla en la declaración friend.
Si no se especifican argumentos de plantilla, la declaración friend declara una función que no es de plantilla.
Para que el código sea válido en las versiones Visual Studio .NET 2003 y Visual Studio .NET 2002 de Visual C++, especifique explícitamente la lista de argumentos de la función friend.
// 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
}
El error LNK2019 también se puede producir por el trabajo de conformidad efectuado en Visual C++ 2005; es decir, /Zc:wchar_t ahora estará activado de manera predeterminada. Es posible que no se hayan compilado todos los módulos mediante la misma configuración de /Zc:wchar_t; por consiguiente, las referencias de tipos no se resolverían como tipos compatibles. Asegúrese de que los tipos de todos los módulos sean compatibles, bien al compilar utilizando los valores adecuados de /Zc:wchar_t (por ejemplo, utilice /Zc:wchar_t- al compilar módulos con las herramientas de Visual C++ que se vinculadas con módulos de versiones anteriores) o, si es posible, actualizando los tipos para que sean compatibles.
Cambie las referencias explícitas a comsupp.lib, bien mediante pragma comment o en la línea de comandos, a omsuppw.lib o comsuppwd.lib; haga esto puesto que ahora /Zc:wchar_t está habilitado de manera predeterminada. Siga usando comsupp.lib cuando compile con /Zc:wchar_t-.
Para obtener más información, vea /Zc:wchar_t (wchar_t es un tipo nativo).
El ejemplo siguiente crea una exportación que utiliza WCHAR, que se resuelve como wchar_t.
// LNK2019g.cpp
// compile with: /LD
#include "windows.h"
// WCHAR resolves to wchar_t
__declspec(dllexport) void func(WCHAR*) {}
En el ejemplo siguiente, se genera el error del vinculador LNK2019.
// LNK2019h.cpp
// compile with: LNK2019g.lib
// LNK2019 expected
__declspec(dllimport) void func(unsigned short*);
int main() {
func(0);
}
Para resolver este error, cambie unsigned short a wchar_t o WCHAR, o compile LNK2019g.cpp utilizando /Zc:wchar_t-.
También puede recibir el error LNK2019 si está compilando una aplicación de consola mediante /SUBSYSTEM:WINDOWS. El símbolo no resuelto será _WinMain@16. En este caso, solo vincule mediante /SUBSYSTEM:CONSOLE.