Как исправить ошибку lnk2019 - Не ошибается лишь тот, кто ничего не делает!

Определение

Данная ошибка означает, что в процессе компоновки программы, компоновщик не смог найти определение некоторой сущности, на которую есть ссылка (попытка использования) в программе.

К таким сущностям может относиться, например, функция или переменная.

Причины и решения

Возможных причин появления ошибки может быть несколько и это зависит от того, что представляет из себя собираемый проект. Всё множество ситуаций можно разбить на две большие группы:

Используются сторонние библиотеки

Не указана необходимая (статическая) библиотека для компоновщика.

Например, к проекту подключен только *.h файл с объявлениями, но отсутствует код реализации, обычно это *.lib или *.a файлы (в зависимости от используемой системы).
Требуется явно подключить библиотеку к проекту.

Для Visual C++ это можно сделать добавлением следующей строки прямо в код:
```
#pragma comment(lib, "libname.lib")
```
Для gcc/clang требуется указать файл через ключ -l (эль)
Для Qt в .pro файле нужно использовать переменную LIBS:
```
LIBS += -L[путь_к_библиотеке] -l[имя_библиотеки]
```
Для системы сборки cmake есть target_link_libraries.

Библиотека указана, но необходимая сущность, например, класс или функция фактически не экспортируется из библиотеки. Под Windows это может возникать из-за отсуствия __declspec(dllexport) перед сущностью. Обычно это решается макросами. Данная ситуация чаще всего характерна именно для библиотек, находящихся в процессе разработки, и доступных для модификации самому разработчику, нежели для каких-то стабильных версий действительно внешних для проекта библиотек. После разрешения экспортирования библиотеку, конечно же, нужно пересобрать перед непосредственным использованием проблемной сущности.
Библиотека указана, но не совпадает разрядность библиотеки и компилируемого кода.

В общем случае, разрядность собираемого проекта (приложения или библиотеки) должна совпадать с разрядностью используемой сторонней библиотеки. Обычно производители библиотек предоставляют возможность выбора 32 или 64 бит версию использовать. Если библиотека поставляется в исходных кодах и собирается отдельно от текущего проекта, нужно также выбрать правильную разрядность.
Библиотека указана, но она собрана для другой (не совместимой) ОС.

Например при сборке проекта в Windows осуществляется попытка использовать бинарный файл, собранный для Linux. В данном случае нужно использовать файлы, подходящие для вашей ОС.
Библиотека указана, но она собрана другим компилятором, не совместимым с используемым.

Объектные файлы, полученные путем сборки C++ кода разными компиляторами для одной и той же ОС могут быть бинарно несовместимы друг с другом. Требуется использовать совместимые (скорее всего и вовсе одинаковые) компиляторы.
Библиотека указана, и собрана тем же компилятором, что и основной проект, но используются разные версии Run-Time библиотек.

Например, для Visual C++ возможна ситуация, когда библиотека собрана с ключом /MDd, а основной проект с /MTd. Требуется задать ключи так, чтобы использовались одинаковые версии Run-Time библиотек.

Сторонние библиотеки не используются

Просто отсутствует определение функции.
```
void f(int); // всего лишь объявление. Нет `тела` функции
int main(){  
    f(42);   // undefined reference to `f(int)'
}  
```
Требуется добавить определение функции f:
```
void f(int) {
    // тело функции
}
```
Может быть ещё частный случай с ошибкой вида:
```
undefined reference to `vtable for <имя_класса>`
```
Такая ошибка возникает, если объявленная виртуальная функция класса, не являющаяся чистой (=0), не содержит реализации.
```
class C {
    virtual void f(int);
};
```
Нужно такую реализацию добавить. Если это делается вне класса, надо не забыть указать имя проблемного класса, иначе это будет просто свободная функция, которая не устраняет указанную проблему:
```
void C::f(int) { // виртуальная функция-член вне определения класса
    // тело функции  
} 

void f(int) { // свободная функция, не устраняющая проблему
    // тело функции 
} 
```
Аналогичная ситуация может возникать при использовании пространств имён, когда объявлении функции находится в пространстве имён:
```
// В заголовочном файле
namespace N {
    void f(int);
};    
```
а при реализации указать это пространство имён забыли:
```
// В файле реализации
void f(int) { // функция в глобальном пространстве имён, не устраняющая проблему
    // тело функции  
}

namespace N {
void f(int) { // функция в нужном пространстве имён
    // тело функции  
}
} // конец пространства имён
```
Стоит заметить, что C++ разрешает перегрузку функций (существование одноимённых функций, но с разным набором параметров), и в этом случае важно, чтобы сигнатуры функций при объявлении и определении совпадали. Например, вместо объявленной void f(int) была реализована другая:
```
void f(const char*) { // const char* вместо int
    // тело функции     
}
```
При вызове f(42) будет ошибка:
```
undefined reference to `f(int)'
```
Наличие связки шаблонного класса и дружественной функции также может приводить к ошибке. Например:
```
template <class T>
struct C {
    friend void f(C<T>);   // объявляет *НЕ*шаблонную дружественную функцию
};

template <class T>         // определяет шаблонную функцию 
void f(C<T>) { }

int main() {
    C<int> c;
    f(c);                  // undefined reference to `f(C<int>)'
}
```
Чтобы объявить шаблонную дружественную функцию, требуется добавить указание шаблонности:
```
template <class T>
struct C {
    template <class V>     // добавили шаблонность для friend функции
    friend void f(C<T>);
};
```
Важно, что имя шаблонного параметра для дружественной функции должно отличаться от имени параметра шаблонного класса T, т.к. иначе будет ошибка о сокрытии имени. В частном случае имя класса можно вовсе не указывать, и оставить template <class>. Но это не всегда будет правильным решением, т.к. фактически могла потребоваться дружественная специализация шаблона функции, а не сама шаблонная функция. Подробнее об использовании дружественных функций в шаблонном классе можно ознакомиться здесь.
Отсутствует определение статической переменной класса.
```
struct S {
    static int i;
};

int main() {
    S s;
    s.i = 42;  // undefined reference to `S::i'
}
```
Нужно добавить определение (выделить память) переменной:
```
int S::i;
```
Неправильная реализация шаблонного кода.

Например, реализация шаблонного кода помещена в *.cpp файл, хотя она должна находиться полностью в подключаемом *.h файле. Это требуется по той причине, что компилятор обрабатывает каждый модуль независимо, и в момент инстанцирования шаблона (подстановки конкретного типа) код его реализации должен быть виден. При этом если возможные типы шаблона известны заранее, можно произвести инстанцирование сразу рядом с телом шаблона и не предоставлять его наружу в исходном коде заголовочного файла. Пример:
```
// unit.h
#pragma once

template <class T>
T f(T);                    // объявление шаблона без реализации
```
```
// unit.cpp
#include "unit.h"

template <class T>
T f(T t) { return t + t; } // реализация шаблона

template
int f<int>(int);           // явное инстанцирование для int

template
double f<double>(double);  // явное инстанцирование для double
```
```
// main.cpp
#include "unit.h"

int main() { 
    f(2);   // ok int
    f(1.5); // ok double
    f('a'); // undefined reference to `char f<char>(char)'
}
```
Файл с кодом не был скомпилирован.

Например, в случае использования make-файла не было прописано правило построения файла, а в случае использования IDE типа Visual Studio *.cpp файл не добавлен в список файлов проекта.
Виртуальная функция в базовом классе не объявлена как = 0 (pure-virtual).
```
struct B {
    void virtual f();
};

struct D : B {
    void f() {}
};

int main() {
    D d;
}
```
При использовании иерархии классов функция в базовом классе, не имеющая реализации должна быть помечена как «чистая»:
```
struct B {
    void virtual f() = 0;
};
```
Имя не имеет внешнего связывания.

Например, есть объявление функции f в модуле А и даже ее реализация в модуле B, но реализация помечена как static:
```
// A.cpp
void f();
int main() {
    f();   // undefined reference to `f()'
}

// B.cpp
static void f() {}
```
Аналогичная ситуация может возникнуть при использовании безымянного пространства имен:
```
// B.cpp
namespace {
   void f() {}
}
```
Или даже при наличии inline у функции:
```
// B.cpp
inline void f() {}
```

Источник

15.07.2012, 16:53. Показов 61359. Ответов 13

Попытался скомпилировать программу из книги (DerectX — это просто. Программируем графику на С++) в Visual C++ 2010 Express, получил ошибки компиляции.

Вот вывод

1>—— Построение начато: проект: DX10Text, Конфигурация: Debug Win32 ——
1> main.cpp
1>main.obj : error LNK2019: ссылка на неразрешенный внешний символ _D3DX10CreateFontW@48 в функции «long __cdecl InitDirect3D10(void)» (?InitDirect3D10@@YAJXZ)
1>main.obj : error LNK2019: ссылка на неразрешенный внешний символ _D3D10CreateDeviceAndSwapChain@32 в функции «long __cdecl InitDirect3D10(void)» (?InitDirect3D10@@YAJXZ)
1>C:ПрогиПроги на C++DrectX 10Glava4TextDebugDX10Text.exe : fatal error LNK1120: 2 неразрешенных внешних элементов
========== Построение: успешно: 0, с ошибками: 1, без изменений: 0, пропущено: 0 ==========

Если понадобится, тогда вот код

Код

[CPP]//--------------------------------------------------------------------------------------
//  Вывод текста на экран
//--------------------------------------------------------------------------------------

#include <windows.h>
#include <d3d10.h>
#include <d3dx10.h>

// Ширина и высота окна
#define WINDOW_WIDTH  640
#define WINDOW_HEIGHT 480

//--------------------------------------------------------------------------------------
// Глобальные переменные
//--------------------------------------------------------------------------------------
HWND        g_hWnd = NULL;
D3D10_DRIVER_TYPE       g_driverType = D3D10_DRIVER_TYPE_NULL;
ID3D10Device*           g_pd3dDevice = NULL;
IDXGISwapChain*         g_pSwapChain = NULL;
ID3D10RenderTargetView* g_pRenderTargetView = NULL;

LPD3DX10FONT			g_pFont = NULL;

//--------------------------------------------------------------------------------------
// Прототипы функций
//--------------------------------------------------------------------------------------
HRESULT             InitWindow( HINSTANCE hInstance, int nCmdShow );
HRESULT				InitDirect3D10();
LRESULT CALLBACK    WndProc(HWND, UINT, WPARAM, LPARAM);
void                Cleanup();
void                RenderScene();

//--------------------------------------------------------------------------------------
// С этой функции начинается выполнение программы
//--------------------------------------------------------------------------------------
int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow )
{
    // Создаем окно приложения
	if( FAILED( InitWindow( hInstance, nCmdShow ) ) )
        return 0;
    // Инициализируем Direct3D
	if( FAILED( InitDirect3D10() ) )
    {
        Cleanup();
        return 0;
    }

    // Цикл обработки сообщений
    MSG msg = {0};
    while( WM_QUIT != msg.message  )
    {
		if( PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ) )
		{
        TranslateMessage( &msg );
        DispatchMessage( &msg );
		}
		else
		{
			RenderScene();
		}

    }

    return (int) msg.wParam;
}

//--------------------------------------------------------------------------------------
// Регистрация класса и создание окна
//--------------------------------------------------------------------------------------
HRESULT InitWindow( HINSTANCE hInstance, int nCmdShow )
{
    // Регистрируем класс окна
    WNDCLASSEX wc;
    wc.cbSize = sizeof(WNDCLASSEX); 
    wc.style          = CS_HREDRAW | CS_VREDRAW;
    wc.lpfnWndProc    = WndProc;
    wc.cbClsExtra     = 0;
    wc.cbWndExtra     = 0;
    wc.hInstance      = hInstance;
    wc.hIcon          = NULL;
    wc.hCursor        = LoadCursor(NULL, IDC_ARROW);
    wc.hbrBackground  = (HBRUSH)(COLOR_WINDOW+1);
    wc.lpszMenuName   = NULL;
    wc.lpszClassName  = L"SimpleWindowClass";
    wc.hIconSm        = LoadIcon(NULL, IDI_APPLICATION);
    if( !RegisterClassEx(&wc) )
        return E_FAIL;

    // Создаем окно
    g_hWnd = CreateWindow(
		L"SimpleWindowClass", 
		L"DirectX 10: Вывод текста", 
		WS_OVERLAPPEDWINDOW,
		CW_USEDEFAULT, 
		CW_USEDEFAULT, 
		WINDOW_WIDTH,
		WINDOW_HEIGHT,
		NULL,
		NULL,
		hInstance,
		NULL);

	// Если не удалось создать окно - выходим из функции
    if( !g_hWnd )
        return E_FAIL;
	// Отображаем окно на экране
    ShowWindow( g_hWnd, nCmdShow );
	UpdateWindow(g_hWnd);
   
    return S_OK;
}

//--------------------------------------------------------------------------------------
// Инициализация Direct3D
//--------------------------------------------------------------------------------------
HRESULT InitDirect3D10()
{
	HRESULT hr = S_OK;

	// Узнаем размеры клиентской области окна
    RECT rc;
    GetClientRect( g_hWnd, &rc );
    UINT width = rc.right - rc.left;
    UINT height = rc.bottom - rc.top;

	// Список возможных типов устройства
	D3D10_DRIVER_TYPE driverTypes[] = 
    {
        D3D10_DRIVER_TYPE_HARDWARE,
        D3D10_DRIVER_TYPE_REFERENCE,
    };
    UINT numDriverTypes = sizeof(driverTypes) / sizeof(driverTypes[0]);

	// Заполняем структуру 
    DXGI_SWAP_CHAIN_DESC sd;
    ZeroMemory( &sd, sizeof(sd) );
    sd.BufferCount = 1;
    sd.BufferDesc.Width = width;
    sd.BufferDesc.Height = height;
    sd.BufferDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM;
    sd.BufferDesc.RefreshRate.Numerator = 60;
    sd.BufferDesc.RefreshRate.Denominator = 1;
    sd.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT;
    sd.OutputWindow = g_hWnd;
    sd.SampleDesc.Count = 1;
    sd.SampleDesc.Quality = 0;
    sd.Windowed = TRUE;

	// Пытаемся создать устройство, проходя по списку
	// как только получилось - выходим из цикла
	for( UINT driverTypeIndex = 0; driverTypeIndex < numDriverTypes; driverTypeIndex++ )
	{
		g_driverType = driverTypes[driverTypeIndex];
		hr = D3D10CreateDeviceAndSwapChain( NULL, g_driverType, NULL, 0, 
			D3D10_SDK_VERSION, &sd, &g_pSwapChain, &g_pd3dDevice );
		if( SUCCEEDED( hr ) )
			break;
	}
	if( FAILED(hr) )
		return hr;

	// Представление данных для
	// буфера визуализации
	ID3D10Texture2D *pBackBuffer;
	hr = g_pSwapChain->GetBuffer( 0, __uuidof( ID3D10Texture2D ), (LPVOID*)&pBackBuffer );
	if( FAILED(hr) )
		return hr;
   // Создадим представление данных
	hr = g_pd3dDevice->CreateRenderTargetView( pBackBuffer, NULL, &g_pRenderTargetView );
	pBackBuffer->Release();
	if( FAILED(hr) )
		return hr;
   // Свяжем буфер визуализации с графическим конвейером
	g_pd3dDevice->OMSetRenderTargets( 1, &g_pRenderTargetView, NULL );

	// Настроим область отображения
	D3D10_VIEWPORT vp;
	vp.Width = width;
	vp.Height = height;
	vp.MinDepth = 0.0f;
	vp.MaxDepth = 1.0f;
	vp.TopLeftX = 0;
	vp.TopLeftY = 0;
	g_pd3dDevice->RSSetViewports( 1, &vp );

	// Создаем шрифтовой объект
	D3DX10CreateFont( g_pd3dDevice, 14, 8, 1, 1, FALSE, 0, 0, 0, DEFAULT_PITCH|FF_MODERN, L"Verdana", &g_pFont);

    return S_OK;
}

//--------------------------------------------------------------------------------------
// Прорисовка трехмерной сцены
//--------------------------------------------------------------------------------------
void RenderScene()
{
    // Очищаем вторичный буфер
    float ClearColor[4] = { 0.1f, 0.5f, 0.1f, 1.0f }; //компоненты красного, зеленого, синего, прозрачность
    g_pd3dDevice->ClearRenderTargetView( g_pRenderTargetView, ClearColor );

	//Размеры прямоугольника для форматирования текста
	RECT Rect;
	Rect.left=10;
	Rect.top=10;
	Rect.right=600;
	Rect.bottom=380;

	g_pFont->DrawText(NULL, L"Этот текст мы вывели на экран", -1, &Rect, DT_CENTER | DT_VCENTER , D3DXCOLOR(1.0,1.0,1.0,1.0));

	g_pSwapChain->Present( 0, 0 );
}
//--------------------------------------------------------------------------------------
// Обработка сообщений
//--------------------------------------------------------------------------------------
LRESULT CALLBACK WndProc( HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam )
{    
    switch (message) 
    {
        
        case WM_DESTROY:
            PostQuitMessage(0);
            break;

        default:
            return DefWindowProc(hWnd, message, wParam, lParam);
    }

    return 0;
}

//--------------------------------------------------------------------------------------
// Очищаем память 
//--------------------------------------------------------------------------------------
void Cleanup()
{
    if( g_pd3dDevice ) g_pd3dDevice->ClearState();

    if( g_pRenderTargetView ) g_pRenderTargetView->Release();
    if( g_pSwapChain ) g_pSwapChain->Release();
    if( g_pd3dDevice ) g_pd3dDevice->Release();

	if( g_pFont ) g_pFont->Release();
}
[/CPP]

Подскажите, что сделать, чтобы убрать эти ошибки.

Источник

title

description

ms.date

f1_keywords

helpviewer_keywords

no-loc

Linker Tools Error LNK2019

All about the Microsoft Visual Studio Linker error LNK2019 and how to diagnose and correct it in C and C++ code.

09/07/2022

LNK2019

nochkclr.obj

LNK2019

_check_commonlanguageruntime_version

main

WinMain

wmain

wWinMain

__cdecl

__stdcall

__fastcall

__vectorcall

extern

static

const

ARCH

AVX2

wchar_t

VERBOSE

EXPORTS

SYMBOLS

DUMPBIN

UNDNAME

unresolved external symbol ‘symbol‘ referenced in function ‘function‘

The compiled code for function makes a reference or call to symbol, but the linker can’t find the symbol definition in any of the libraries or object files.

This error message is followed by fatal error LNK1120. To fix error LNK1120, you must fix all LNK2001 and LNK2019 errors first.

Possible causes

There are many ways to get this error. All of them involve a reference to a function or variable that the linker couldn’t resolve, or find a definition for. The compiler can identify when a symbol isn’t declared, but it can’t tell when the symbol isn’t defined. It’s because the definition may be in a different source file or library. If a symbol is referred to but never defined, the linker generates an unresolved external symbol error.

Here are some common problems that cause LNK2019:

The source file that contains the definition of the symbol isn’t compiled

In Visual Studio, make sure the source file that defines the symbol gets compiled as part of your project. Check the intermediate build output directory for a matching .obj file. If the source file isn’t compiled, right-click on the file in Solution Explorer, and then choose Properties to check the properties of the file. The Configuration Properties > General page should show an Item Type of C/C++ Compiler. On the command line, make sure the source file that contains the definition is compiled.

The object file or library that contains the definition of the symbol isn’t linked

In Visual Studio, make sure the object file or library that contains the symbol definition is linked as part of your project. On the command line, make sure the list of files to link includes the object file or library.

The declaration of the symbol isn’t spelled the same as the definition of the symbol

Verify you use the correct spelling and capitalization in both the declaration and the definition, and wherever the symbol is used or called.

A function is used but the type or number of the parameters don’t match the function definition

The function declaration must match the definition. Make sure the function call matches the declaration, and that the declaration matches the definition. Code that invokes function templates must also have matching function template declarations that include the same template parameters as the definition. For an example of a template declaration mismatch, see sample LNK2019e.cpp in the Examples section.

A function or variable is declared but not defined

LNK2019 can occur when a declaration exists in a header file, but no matching definition is implemented. For member functions or static data members, the implementation must include the class scope selector. For an example, see Missing Function Body or Variable.

The calling convention is different between the function declaration and the function definition

Some calling conventions (__cdecl, __stdcall, __fastcall, and __vectorcall) are encoded as part of the decorated name. Make sure the calling convention is the same.

A symbol is defined in a C file, but declared without using `extern "C"` in a C++ file

A file that’s compiled as C creates decorated names for symbols that are different from the decorated names for the same symbols declared in a C++ file, unless you use an extern "C" modifier. Make sure the declaration matches the compilation linkage for each symbol. Similarly, if you define a symbol in a C++ file that will be used by a C program, use extern "C" in the definition.

A symbol is defined as static and then later referenced outside the file

In C++, unlike C, global constants have static linkage. To get around this limitation, you can include the const initializations in a header file and include that header in your .cpp files, or you can make the variable non-constant and use a constant reference to access it.

A static member of a class isn’t defined

A static class member must have a unique definition, or it will violate the one-definition rule. A static class member that can’t be defined inline must be defined in one source file by using its fully qualified name. If it isn’t defined at all, the linker generates LNK2019.

A build dependency is only defined as a project dependency in the solution

In earlier versions of Visual Studio, this level of dependency was sufficient. However, starting with Visual Studio 2010, Visual Studio requires a project-to-project reference. If your project doesn’t have a project-to-project reference, you may receive this linker error. Add a project-to-project reference to fix it.

An entry point isn’t defined

The application code must define an appropriate entry point: main or wmain for console applications, and WinMain or wWinMain for Windows applications. For more information, see main function and command-line arguments or WinMain function. To use a custom entry point, specify the /ENTRY (Entry-Point Symbol) linker option.

You build a console application by using settings for a Windows application

If the error message is similar to unresolved external symbol WinMain referenced in function function_name, link by using /SUBSYSTEM:CONSOLE instead of /SUBSYSTEM:WINDOWS. For more information about this setting, and for instructions on how to set this property in Visual Studio, see /SUBSYSTEM (Specify Subsystem).

You attempt to link 64-bit libraries to 32-bit code, or 32-bit libraries to 64-bit code

Libraries and object files linked to your code must be compiled for the same architecture as your code. Make sure the libraries your project references are compiled for the same architecture as your project. Make sure the /LIBPATH or Additional Library Directories property points to libraries built for the correct architecture.

You use different compiler options for function inlining in different source files

Using inlined functions defined in .cpp files and mixing function inlining compiler options in different source files can cause LNK2019. For more information, see Function Inlining Problems.

You use automatic variables outside their scope

Automatic (function scope) variables can only be used in the scope of that function. These variables can’t be declared extern and used in other source files. For an example, see Automatic (Function Scope) Variables.

You call intrinsic functions or pass argument types to intrinsic functions that aren’t supported on your target architecture

For example, if you use an AVX2 intrinsic, but don’t specify the /ARCH:AVX2 compiler option, the compiler assumes that the intrinsic is an external function. Instead of generating an inline instruction, the compiler generates a call to an external symbol with the same name as the intrinsic. When the linker tries to find the definition of this missing function, it generates LNK2019. Make sure you only use intrinsics and types supported by your target architecture.

You mix code that uses native `wchar_t` with code that doesn’t

C++ language conformance work that was done in Visual Studio 2005 made wchar_t a native type by default. If not all files have been compiled by using the same /Zc:wchar_t settings, type references may not resolve to compatible types. Make sure wchar_t types in all library and object files are compatible. Either update from a wchar_t typedef, or use consistent /Zc:wchar_t settings when you compile.

You get errors for `printf` and `scanf` functions when you link a legacy static library

A static library that was built using a version of Visual Studio before Visual Studio 2015 may cause LNK2019 errors when linked with the UCRT. The UCRT header files <stdio.h>, <conio.h>, and <wchar.h>now define many *printf* and *scanf* variations as inline functions. The inlined functions are implemented by a smaller set of common functions. Individual exports for the inlined functions aren’t available in the standard UCRT libraries, which only export the common functions. There are a couple of ways to resolve this issue. The method we recommend is to rebuild the legacy library with your current version of Visual Studio. Make sure the library code uses the standard headers for the definitions of the *printf* and *scanf* functions that caused the errors. Another option for a legacy library that you can’t rebuild is to add legacy_stdio_definitions.lib to the list of libraries you link. This library file provides symbols for the *printf* and *scanf* functions that are inlined in the UCRT headers. For more information, see the Libraries section in Overview of potential upgrade issues.

Third-party library issues and vcpkg

If you see this error when you’re trying to configure a third-party library as part of your build, consider using vcpkg. vcpkg is a C++ package manager that uses your existing Visual Studio tools to install and build the library. vcpkg supports a large and growing list of third-party libraries. It sets all the configuration properties and dependencies required for successful builds as part of your project.

Diagnosis tools

Sometimes it’s difficult to tell why the linker can’t find a particular symbol definition. Often the problem is that you haven’t included the code that contains the definition in your build. Or, build options have created different decorated names for external symbols. There are several tools and options that can help you diagnose LNK2019 errors.

The /VERBOSE linker option can help you determine which files the linker references. This option can help you verify whether the file that contains the definition of the symbol is included in your build.
The /EXPORTS and /SYMBOLS options of the DUMPBIN utility can help you discover which symbols are defined in your .dll and object or library files. Make sure the exported decorated names match the decorated names the linker searches for.
The UNDNAME utility can show you the equivalent undecorated external symbol for a decorated name.

Examples

Here are several examples of code that causes LNK2019 errors, together with information about how to fix the errors.

A symbol is declared but not defined

In this example, an external variable is declared but not defined:

// LNK2019.cpp
// Compile by using: cl /EHsc /W4 LNK2019.cpp
// LNK2019 expected
extern char B[100];   // B isn't available to the linker
int main() {
   B[0] = ' ';   // LNK2019
}

Here’s another example where a variable and function are declared as extern but no definition is provided:

// LNK2019c.cpp
// Compile by using: cl /EHsc LNK2019c.cpp
// LNK2019 expected
extern int i;
extern void g();
void f() {
   i++;
   g();
}
int main() {}

Unless i and g are defined in one of the files included in the build, the linker generates LNK2019. You can fix the errors by including the source code file that contains the definitions as part of the compilation. Alternatively, you can pass .obj files or .lib files that contain the definitions to the linker.

A static data member is declared but not defined

LNK2019 can also occur when a static data member is declared but not defined. The following sample generates LNK2019, and shows how to fix it.

// LNK2019b.cpp
// Compile by using: cl /EHsc LNK2019b.cpp
// LNK2019 expected
struct C {
   static int s;
};

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

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

Declaration parameters don’t match the definition

Code that invokes function templates must have matching function template declarations. Declarations must include the same template parameters as the definition. The following sample generates LNK2019 on a user-defined operator, and shows how to fix it.

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

template<class T> class
Test {
   // The operator<< declaration doesn't match the definition below:
   friend ostream& operator<<(ostream&, Test&);
   // To fix, replace the line above with the following:
   // 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;   // LNK2019 unresolved external
}

Inconsistent wchar_t type definitions

This sample creates a DLL that has an export that uses WCHAR, which resolves to wchar_t.

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

The next sample uses the DLL in the previous sample, and generates LNK2019 because the types unsigned short* and WCHAR* aren’t the same.

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

int main() {
   func(0);
}

To fix this error, change unsigned short to wchar_t or WCHAR, or compile LNK2019g.cpp by using /Zc:wchar_t-.

Определение

К таким сущностям может относиться, например, функция или переменная.

Причины и решения

Используются сторонние библиотеки

Не указана необходимая (статическая) библиотека для компоновщика.

Например, к проекту подключен только *.h файл с объявлениями, но отсутствует код реализации, обычно это *.lib или *.a файлы (в зависимости от используемой системы).
Требуется явно подключить библиотеку к проекту.

Для Visual C++ это можно сделать добавлением следующей строки прямо в код:
```
#pragma comment(lib, "libname.lib") 
```
Для gcc/clang требуется указать файл через ключ -l (эль)
Для Qt в .pro файле нужно использовать переменную LIBS:
```
LIBS += -L[путь_к_библиотеке] -l[имя_библиотеки] 
```
Для системы сборки cmake есть target_link_libraries.

Библиотека указана, но необходимая сущность, например, класс или функция фактически не экспортируется из библиотеки. Под Windows это может возникать из-за отсуствия __declspec(dllexport) перед сущностью. Обычно это решается макросами. Данная ситуация чаще всего характерна именно для библиотек, находящихся в процессе разработки, и доступных для модификации самому разработчику, нежели для каких-то стабильных версий действительно внешних для проекта библиотек. После разрешения экспортирования библиотеку, конечно же, нужно пересобрать перед непосредственным использованием проблемной сущности.
Библиотека указана, но не совпадает разрядность библиотеки и компилируемого кода.

В общем случае, разрядность собираемого проекта (приложения или библиотеки) должна совпадать с разрядностью используемой сторонней библиотеки. Обычно производители библиотек предоставляют возможность выбора 32 или 64 бит версию использовать. Если библиотека поставляется в исходных кодах и собирается отдельно от текущего проекта, нужно также выбрать правильную разрядность.
Библиотека указана, но она собрана для другой (не совместимой) ОС.

Например при сборке проекта в Windows осуществляется попытка использовать бинарный файл, собранный для Linux. В данном случае нужно использовать файлы, подходящие для вашей ОС.
Библиотека указана, но она собрана другим компилятором, не совместимым с используемым.

Объектные файлы, полученные путем сборки C++ кода разными компиляторами для одной и той же ОС могут быть бинарно несовместимы друг с другом. Требуется использовать совместимые (скорее всего и вовсе одинаковые) компиляторы.
Библиотека указана, и собрана тем же компилятором, что и основной проект, но используются разные версии Run-Time библиотек.

Например, для Visual C++ возможна ситуация, когда библиотека собрана с ключом /MDd, а основной проект с /MTd. Требуется задать ключи так, чтобы использовались одинаковые версии Run-Time библиотек.

Сторонние библиотеки не используются

Просто отсутствует определение функции.
```
void f(int); // всего лишь объявление. Нет `тела` функции int main(){ f(42); // undefined reference to `f(int)' } 
```
Требуется добавить определение функции f:
```
void f(int) { // тело функции } 
```
Может быть ещё частный случай с ошибкой вида:
```
undefined reference to `vtable for <имя_класса>` 
```
Такая ошибка возникает, если объявленная виртуальная функция класса, не являющаяся чистой (=0), не содержит реализации.
```
class C { virtual void f(int); }; 
```
Нужно такую реализацию добавить. Если это делается вне класса, надо не забыть указать имя проблемного класса, иначе это будет просто свободная функция, которая не устраняет указанную проблему:
```
void C::f(int) { // виртуальная функция-член вне определения класса // тело функции } void f(int) { // свободная функция, не устраняющая проблему // тело функции } 
```
Аналогичная ситуация может возникать при использовании пространств имён, когда объявлении функции находится в пространстве имён:
```
// В заголовочном файле namespace N { void f(int); }; 
```
а при реализации указать это пространство имён забыли:
```
// В файле реализации void f(int) { // функция в глобальном пространстве имён, не устраняющая проблему // тело функции } namespace N { void f(int) { // функция в нужном пространстве имён // тело функции } } // конец пространства имён 
```
Стоит заметить, что C++ разрешает перегрузку функций (существование одноимённых функций, но с разным набором параметров), и в этом случае важно, чтобы сигнатуры функций при объявлении и определении совпадали. Например, вместо объявленной void f(int) была реализована другая:
```
void f(const char*) { // const char* вместо int // тело функции } 
```
При вызове f(42) будет ошибка:
```
undefined reference to `f(int)' 
```
Наличие связки шаблонного класса и дружественной функции также может приводить к ошибке. Например:
```
template <class T> struct C { friend void f(C<T>); // объявляет *НЕ*шаблонную дружественную функцию }; template <class T> // определяет шаблонную функцию void f(C<T>) { } int main() { C<int> c; f(c); // undefined reference to `f(C<int>)' } 
```
Чтобы объявить шаблонную дружественную функцию, требуется добавить указание шаблонности:
```
template <class T> struct C { template <class V> // добавили шаблонность для friend функции friend void f(C<T>); }; 
```
Важно, что имя шаблонного параметра для дружественной функции должно отличаться от имени параметра шаблонного класса T, т.к. иначе будет ошибка о сокрытии имени. В частном случае имя класса можно вовсе не указывать, и оставить template <class>. Но это не всегда будет правильным решением, т.к. фактически могла потребоваться дружественная специализация шаблона функции, а не сама шаблонная функция. Подробнее об использовании дружественных функций в шаблонном классе можно ознакомиться здесь.
Отсутствует определение статической переменной класса.
```
struct S { static int i; }; int main() { S s; s.i = 42; // undefined reference to `S::i' } 
```
Нужно добавить определение (выделить память) переменной:
```
int S::i; 
```
Неправильная реализация шаблонного кода.

Например, реализация шаблонного кода помещена в *.cpp файл, хотя она должна находиться полностью в подключаемом *.h файле. Это требуется по той причине, что компилятор обрабатывает каждый модуль независимо, и в момент инстанцирования шаблона (подстановки конкретного типа) код его реализации должен быть виден. При этом если возможные типы шаблона известны заранее, можно произвести инстанцирование сразу рядом с телом шаблона и не предоставлять его наружу в исходном коде заголовочного файла. Пример:
```
// unit.h #pragma once template <class T> T f(T); // объявление шаблона без реализации 
```
```
// unit.cpp #include "unit.h" template <class T> T f(T t) { return t + t; } // реализация шаблона template int f<int>(int); // явное инстанцирование для int template double f<double>(double); // явное инстанцирование для double 
```
```
// main.cpp #include "unit.h" int main() { f(2); // ok int f(1.5); // ok double f('a'); // undefined reference to `char f<char>(char)' } 
```
Файл с кодом не был скомпилирован.

Например, в случае использования make-файла не было прописано правило построения файла, а в случае использования IDE типа Visual Studio *.cpp файл не добавлен в список файлов проекта.
Виртуальная функция в базовом классе не объявлена как = 0 (pure-virtual).
```
struct B { void virtual f(); }; struct D : B { void f() {} }; int main() { D d; } 
```
При использовании иерархии классов функция в базовом классе, не имеющая реализации должна быть помечена как «чистая»:
```
struct B { void virtual f() = 0; }; 
```
Имя не имеет внешнего связывания.

Например, есть объявление функции f в модуле А и даже ее реализация в модуле B, но реализация помечена как static:
```
// A.cpp void f(); int main() { f(); // undefined reference to `f()' } // B.cpp static void f() {} 
```
Аналогичная ситуация может возникнуть при использовании безымянного пространства имен:
```
// B.cpp namespace { void f() {} } 
```
Или даже при наличии inline у функции:
```
// B.cpp inline void f() {} 
```

одним из вариантов было бы включить function.cpp в своем UnitTest1 проект, но это может быть не самая идеальная структура решения. Короткий ответ на вашу проблему заключается в том, что при создании вашего UnitTest1 проект, компилятор и компоновщик понятия не имеют, что function.cpp существует, а также не имеют ничего, чтобы связать, что содержит определение multiple. Способ исправить это-использовать библиотеки ссылок.

поскольку ваши модульные тесты находятся в другом проекте, я предполагаю, что ваше намерение состоит в том, чтобы сделайте этот проект автономной программой модульного тестирования. С функциями, которые вы тестируете, расположенными в другом проекте, можно построить этот проект в динамически или статически связанной библиотеке. Статические библиотеки связаны с другими программами во время сборки, и имеют расширение .lib, и динамические библиотеки связаны во время выполнения, и имеют расширение .dll. Для моего ответа я предпочитаю статические библиотеки.

вы можете превратить свою первую программу в статическую библиотеку изменив его в свойствах проектов. Там должна быть опция на вкладке Общие, где проект настроен на сборку в исполняемый файл (.exe). Вы можете изменить это на .lib. Элемент .lib файл будет построен в том же месте, что и .exe.

в своем UnitTest1 проект, вы можете перейти к его свойствам, и на вкладке Компоновщик в категории дополнительные каталоги библиотеки, добавить путь к которому MyProjectTest строит. Затем, для получения дополнительных зависимостей под Компоновщик — Вкладка ввода, добавьте имя вашей статической библиотеки, скорее всего MyProjectTest.lib.

это должно позволить вашему проекту построить. Обратите внимание, что, делая это, MyProjectTest не будет автономной исполняемой программой, если вы не измените ее свойства сборки по мере необходимости, что было бы менее идеальным.

Не могу разобраться в чем проблема… я написал небольшую програмку скомпилировал, а когда через некоторое время внес исправления и попытался исправить получил кучу ошибок:

error LNK2019: unresolved external symbol __imp__fread referenced in function «int __cdecl ReadKZU(struct _iobuf *,unsigned int *)» (?ReadKZU@@YAHPAU_iobuf@@PAI@Z)

и так 33 раза на разных функциях…
Теперь у меня ни один проект не компилится:(((…В чем проблема?

31 ответ

05 декабря 2006 года

Zorkus

2.6K / / 04.11.2006

Код давай. Надо с ключами линкера поколдовать, думаю:)

8.2K

05 декабря 2006 года

mohito

35 / / 24.11.2005

В прикрепленном файле код… там две функции одна другую вызывает…
P.S. сам код «корявый», но не в этом суть….

8.2K

06 декабря 2006 года

mohito

35 / / 24.11.2005

Если есть добрые люди, кому не жаль потратить полчасика… скиньте в каком-нибудь виде свои настройки проекта MSVS 2005… я подозреваю что проблема именно в настройках проекта… но никак не могу понять где именно… я уже сократил кол-во ошибок с 33 до 6… =)

240

06 декабря 2006 года

aks

2.5K / / 14.07.2006

)
Зайди в свойства проекта->C/C++ ->Code Generation -> Runtime Library
и скажи, что у тебя там стоит.

240

06 декабря 2006 года

aks

2.5K / / 14.07.2006

Кстати накой консольной программе мессаджбоксы? Неужели нельзя сообщение об ошибке тудаже в консоль и выдать?

8.2K

06 декабря 2006 года

mohito

35 / / 24.11.2005

1. В Runtime Library: Multi-threaded Debug DLL /MDd
2. Это кусок программы, я написал его как консольное приложение, но потом код вставлю в MFC проект. короче не важно, какая разница где-мессадж боксы вызывать=)

240

06 декабря 2006 года

aks

2.5K / / 14.07.2006

Поставь статический рантайм. Чтоб не было написанно DLL, и расскажи что произошло )

06 декабря 2006 года

Zorkus

2.6K / / 04.11.2006

mohito, а что соббсна пишет хелп про эту ошибку, можешь кинуть?
P.S. прошу прощения, но MSVS и msdn нету на машине…

8.2K

06 декабря 2006 года

mohito

35 / / 24.11.2005

Исправил Runtime Library: Multi-threaded Debug (/MTd)
Кол-во ошибок увеличилось с 6 до 31 =)…
в начале что-то вроде:
error LNK2005: «public: __thiscall std::_Locinfo::_Locinfo(char const *)…
и так раз 5
потом
LNK2019…
много раз…

8.2K

06 декабря 2006 года

mohito

35 / / 24.11.2005

Здесь пример сообщений об ошибках:

06 декабря 2006 года

Zorkus

2.6K / / 04.11.2006

Я спросил статью справки, F1 + click на сообщение об ошибке, статью про возможную причину, а не то что пишет компилятор.

8.2K

06 декабря 2006 года

mohito

35 / / 24.11.2005

А… Момент=)…. смотри в файле:

5.9K

07 декабря 2006 года

Zushenskiy

161 / / 29.06.2006

mohito ты какой проект создаешь?

279

07 декабря 2006 года

bave

456 / / 07.03.2004

Если ставить Code Generation: MultiThread надо чтоб все остальные линкуемые модули (написанные тобой) тоже были откомпилированы с
ключём /MT — иначе линковшик выдаёт кучу ошибок о конфликтах
LIBC и LIBCMT…

8.2K

07 декабря 2006 года

mohito

35 / / 24.11.2005

У меня простой консольный проект, из одного файла.

5.9K

07 декабря 2006 года

Zushenskiy

161 / / 29.06.2006

Выложи проект либо содиржимое файла vcproj

8.2K

07 декабря 2006 года

mohito

35 / / 24.11.2005

Вот vsproj:

07 декабря 2006 года

Zorkus

2.6K / / 04.11.2006

Попробуй ключи линкера (свойства проекта, общие, линкер, ком. строка, как-то так) /FORCE , /Zc:wchar_t- .

8.2K

07 декабря 2006 года

mohito

35 / / 24.11.2005

Ага… добавление в Linker->ComandLine опции /FORCE позволило снять ошибку 2019…. теперь прога компилируется(и линкуется) но при запуске выдает: ненайден библиотека MSVCP60D.dll =)… И прикол в том что у меня её нет=) (я искал везде)

07 декабря 2006 года

Zorkus

2.6K / / 04.11.2006

http://intercomp.net.ru/dll/m.php?page=82
там нужные либы есть, но все таки почитай подробнее про ключ /FORCE, он ведь многое ставит в игнор, с ним лучше осторожно (хотя, иногда,мне кажется, только он и спасает:))

8.2K

07 декабря 2006 года

mohito

35 / / 24.11.2005

Да, походу /FORCE — сильная штука=)… Т.к. я сумел скомпилировать, но ткпкрь при попытке открыть файл (fopen) уменя возникает Exception (Исключение) =))) (я не вносил изменений в код.. который когда-то запускался=) )… Должен же быть способ кроме как все «зафорсить»?… Или Винду переустанавливать??? (студию переустанавливал трижды… не помогло)

07 декабря 2006 года

Zorkus

2.6K / / 04.11.2006

какой именно exception?

5.9K

08 декабря 2006 года

Zushenskiy

161 / / 29.06.2006

твой vcproj настроен нормально. походу проблемы либо с виндой либо со студией. линковщик неможет найти подходящие либы. проверь настройки и переменные окружения самой студии. и погоняй свой комп на инородные прожки типа вирусы.

08 декабря 2006 года

Zorkus

2.6K / / 04.11.2006

линковщик неможет найти подходящие либы. проверь настройки и переменные окружения самой студии. и погоняй свой комп на инородные прожки типа вирусы.

Надо скачать dll-ку и кинуть в каталог где храняться dll -ки VS, или в system32, хидер к ней как я понимаю, есть (или он не нужен), а lib — файл для либы можно самому сделать, если надо, точно не скажу как утилитка из VS называется, implib вроде бы, и бросить его туда где все остальные находятся у студии, вот и вся настройка линкера ( это в общем, для абстрактной dll, а для динамически загр. вроде твоей нужна только сама dll и все).
Переменные окружения должны при установке ставиться сами, а вирусы — так с этого надо было начинать;)

8.2K

09 декабря 2006 года

mohito

35 / / 24.11.2005

Проблема решена… Сносом Винды и полной переустановкой системы=))).
Всем МЕГА спасибо за участие в топике…

09 декабря 2006 года

Zorkus

2.6K / / 04.11.2006

Проблема решена… Сносом Винды и полной переустановкой системы=))).

Это называется «решена»?:) Ты скажи, стало работать нормально, или нет? И какая именно была ошибка неустранимая? Я из твоего описания не понял.

8.2K

09 декабря 2006 года

mohito

35 / / 24.11.2005

Решана — значит ошибка больше не возникает…. После переустановки Windows и Visual Studio, соответствено все проекты стали нормально компилироваться…
Я предпологаю что проблема все таки была связана с вирусом Nashta (или что-то наподобе) который я обнаружил мой антивирус и по его(антивируса) заявлению успешно удалил…

8.2K

13 декабря 2006 года

mohito

35 / / 24.11.2005

Я нашел в чем была проблема!
Вчера запустил Студию и опять вылетела ошибка 2019…. я думал я комп разнесу=)

Потом стал прикидывать от чего это… и вспомнил… за 2 часа до этого установил себе IFS Development Kit for Windows XP и прописал в настройках Visual Studio пути к папакам Inc и Lib из DDK… и эти папки были первыми по порядку… видимо он вних пытался искать и нефига не находил=)

13 декабря 2006 года

Zorkus

2.6K / / 04.11.2006

Сказал бы сразу:)

Сама ошибка:

1>main.obj : error LNK2019: unresolved external symbol "public: static void __cdecl Furdarius::MatrixHelpers::inputFromFile<int>(class Furdarius::Matrix<int> &,class std::basic_fstream<char,struct std::char_traits<char> > &)" (??$inputFromFile@H@MatrixHelpers@Furdarius@@SAXAAV?$Matrix@H@1@AAV?$basic_fstream@DU?$char_traits@D@std@@@std@@@Z) referenced in function "class Furdarius::Matrix<int> __cdecl initMatrixFromFile(class std::basic_fstream<char,struct std::char_traits<char> > &)" (?initMatrixFromFile@@YA?AV?$Matrix@H@Furdarius@@AAV?$basic_fstream@DU?$char_traits@D@std@@@std@@@Z)

Код который ее генерит:

// MatrixHelpers.h class MatrixHelpers { public: template<typename _U> static void inputFromFile(Matrix<_U> &matrix, std::fstream &file);

// MatrixHelpers.cpp template<typename _U> void MatrixHelpers::inputFromFile(Matrix<_U> &matrix, std::fstream &file) { for (int i = 0; i < matrix.getSize().row; ++i) for (int j = 0; j < matrix.getSize().col; ++j) file >> matrix[i][j]; };

Вызов метода в main.cpp

Matrix<int> M(size); MatrixHelpers::inputFromFile<int>(M, file);

title

description

ms.date

f1_keywords

helpviewer_keywords

no-loc

Linker Tools Error LNK2019

All about the Microsoft Visual Studio Linker error LNK2019 and how to diagnose and correct it in C and C++ code.

09/07/2022

LNK2019

nochkclr.obj

LNK2019

_check_commonlanguageruntime_version

main

WinMain

wmain

wWinMain

__cdecl

__stdcall

__fastcall

__vectorcall

extern

static

const

ARCH

AVX2

wchar_t

VERBOSE

EXPORTS

SYMBOLS

DUMPBIN

UNDNAME

unresolved external symbol ‘symbol‘ referenced in function ‘function‘

The compiled code for function makes a reference or call to symbol, but the linker can’t find the symbol definition in any of the libraries or object files.

This error message is followed by fatal error LNK1120. To fix error LNK1120, you must fix all LNK2001 and LNK2019 errors first.

Possible causes

Here are some common problems that cause LNK2019:

The source file that contains the definition of the symbol isn’t compiled

The object file or library that contains the definition of the symbol isn’t linked

The declaration of the symbol isn’t spelled the same as the definition of the symbol

Verify you use the correct spelling and capitalization in both the declaration and the definition, and wherever the symbol is used or called.

A function is used but the type or number of the parameters don’t match the function definition

A function or variable is declared but not defined

The calling convention is different between the function declaration and the function definition

Some calling conventions (__cdecl, __stdcall, __fastcall, and __vectorcall) are encoded as part of the decorated name. Make sure the calling convention is the same.

A symbol is defined in a C file, but declared without using `extern "C"` in a C++ file

A symbol is defined as static and then later referenced outside the file

A static member of a class isn’t defined

A build dependency is only defined as a project dependency in the solution

An entry point isn’t defined

You build a console application by using settings for a Windows application

You attempt to link 64-bit libraries to 32-bit code, or 32-bit libraries to 64-bit code

You use different compiler options for function inlining in different source files

Using inlined functions defined in .cpp files and mixing function inlining compiler options in different source files can cause LNK2019. For more information, see Function Inlining Problems.

You use automatic variables outside their scope

You call intrinsic functions or pass argument types to intrinsic functions that aren’t supported on your target architecture

You mix code that uses native `wchar_t` with code that doesn’t

You get errors for `printf` and `scanf` functions when you link a legacy static library

Third-party library issues and vcpkg

Diagnosis tools

The /VERBOSE linker option can help you determine which files the linker references. This option can help you verify whether the file that contains the definition of the symbol is included in your build.
The /EXPORTS and /SYMBOLS options of the DUMPBIN utility can help you discover which symbols are defined in your .dll and object or library files. Make sure the exported decorated names match the decorated names the linker searches for.
The UNDNAME utility can show you the equivalent undecorated external symbol for a decorated name.

Examples

Here are several examples of code that causes LNK2019 errors, together with information about how to fix the errors.

A symbol is declared but not defined

In this example, an external variable is declared but not defined:

// LNK2019.cpp // Compile by using: cl /EHsc /W4 LNK2019.cpp // LNK2019 expected extern char B[100]; // B isn't available to the linker int main() { B[0] = ' '; // LNK2019 }

Here’s another example where a variable and function are declared as extern but no definition is provided:

// LNK2019c.cpp // Compile by using: cl /EHsc LNK2019c.cpp // LNK2019 expected extern int i; extern void g(); void f() { i++; g(); } int main() {}

A static data member is declared but not defined

LNK2019 can also occur when a static data member is declared but not defined. The following sample generates LNK2019, and shows how to fix it.

// LNK2019b.cpp // Compile by using: cl /EHsc LNK2019b.cpp // LNK2019 expected struct C { static int s; }; // Uncomment the following line to fix the error. // int C::s; int main() { C c; C::s = 1; }

Declaration parameters don’t match the definition

// LNK2019e.cpp // compile by using: cl /EHsc LNK2019e.cpp // LNK2019 expected #include <iostream> using namespace std; template<class T> class Test { // The operator<< declaration doesn't match the definition below: friend ostream& operator<<(ostream&, Test&); // To fix, replace the line above with the following: // 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; // LNK2019 unresolved external }

Inconsistent wchar_t type definitions

This sample creates a DLL that has an export that uses WCHAR, which resolves to wchar_t.

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

The next sample uses the DLL in the previous sample, and generates LNK2019 because the types unsigned short* and WCHAR* aren’t the same.

// LNK2019h.cpp // compile by using: cl /EHsc LNK2019h LNK2019g.lib // LNK2019 expected __declspec(dllimport) void func(unsigned short*); int main() { func(0); }

To fix this error, change unsigned short to wchar_t or WCHAR, or compile LNK2019g.cpp by using /Zc:wchar_t-.

Определение

Причины и решения

Используются сторонние библиотеки

Сторонние библиотеки не используются

Possible causes

The source file that contains the definition of the symbol isn’t compiled

The object file or library that contains the definition of the symbol isn’t linked

The declaration of the symbol isn’t spelled the same as the definition of the symbol

A function is used but the type or number of the parameters don’t match the function definition

A function or variable is declared but not defined

The calling convention is different between the function declaration and the function definition

A symbol is defined in a C file, but declared without using extern "C" in a C++ file

A symbol is defined as static and then later referenced outside the file

A static member of a class isn’t defined

A build dependency is only defined as a project dependency in the solution

An entry point isn’t defined

You build a console application by using settings for a Windows application

You attempt to link 64-bit libraries to 32-bit code, or 32-bit libraries to 64-bit code

You use different compiler options for function inlining in different source files

You use automatic variables outside their scope

You call intrinsic functions or pass argument types to intrinsic functions that aren’t supported on your target architecture

You mix code that uses native wchar_t with code that doesn’t

You get errors for *printf* and *scanf* functions when you link a legacy static library

Third-party library issues and vcpkg

Diagnosis tools

Examples

A symbol is declared but not defined

A static data member is declared but not defined

Declaration parameters don’t match the definition

Inconsistent wchar_t type definitions

See also

Вопрос

Ответы

Определение

Причины и решения

Используются сторонние библиотеки

Сторонние библиотеки не используются

31 ответ

Possible causes

The source file that contains the definition of the symbol isn’t compiled

The object file or library that contains the definition of the symbol isn’t linked

The declaration of the symbol isn’t spelled the same as the definition of the symbol

A function is used but the type or number of the parameters don’t match the function definition

A function or variable is declared but not defined

The calling convention is different between the function declaration and the function definition

A symbol is defined in a C file, but declared without using extern "C" in a C++ file

A symbol is defined as static and then later referenced outside the file

A static member of a class isn’t defined

A build dependency is only defined as a project dependency in the solution

An entry point isn’t defined

You build a console application by using settings for a Windows application

You attempt to link 64-bit libraries to 32-bit code, or 32-bit libraries to 64-bit code

You use different compiler options for function inlining in different source files

You use automatic variables outside their scope

You call intrinsic functions or pass argument types to intrinsic functions that aren’t supported on your target architecture

You mix code that uses native wchar_t with code that doesn’t

You get errors for *printf* and *scanf* functions when you link a legacy static library

Third-party library issues and vcpkg

Diagnosis tools

Examples

A symbol is declared but not defined

A static data member is declared but not defined

Declaration parameters don’t match the definition

Inconsistent wchar_t type definitions

See also

A symbol is defined in a C file, but declared without using `extern "C"` in a C++ file

You mix code that uses native `wchar_t` with code that doesn’t

You get errors for `printf` and `scanf` functions when you link a legacy static library

A symbol is defined in a C file, but declared without using `extern "C"` in a C++ file

You mix code that uses native `wchar_t` with code that doesn’t

You get errors for `printf` and `scanf` functions when you link a legacy static library