LNK2019 Unresolved External Symbol — Find the Missing Definition

What LNK2019 actually proves

Microsoft describes LNK2019 as compiled code referencing a function or variable whose definition the linker cannot find in the libraries or object files it searches. A declaration can therefore be perfectly visible to the compiler while the definition is missing at link time.

Fix #2 — definition is in your source, but that source is missing from the build

A header declaration is not the implementation. Confirm the function/variable has a definition, then confirm the source file containing it participates in the active build. In Visual Studio, a file can exist in the solution while being excluded or configured with the wrong item type.

Do not “fix” this by #include-ing a normal .cpp into another source file. Make the implementation source a proper compilation unit unless the code is intentionally header-only/template-based.

Verify: Build with normal verbosity and confirm the implementation source produces an .obj in the active configuration; rebuild and confirm this symbol is no longer unresolved.

Fix #3 — the definition is in another object/library, but LINK is not receiving it

Proving that something.lib exists on disk—or even that a similarly named symbol can be found somewhere inside it—is not enough. The active link must receive the correct library and LINK must be able to select the member that provides the exact requested decorated symbol. Check project references/linker inputs, effective library search paths and linker evidence for the configuration you are building. With static libraries, remember that libraries are archives of object members: resolution/extraction depends on unresolved references and the actual link inputs/options, so inspect what LINK selects rather than treating archive presence as proof.

Verify: inspect the effective link command and appropriate /VERBOSE evidence to prove the intended library/member is considered or selected for the exact unresolved symbol. Then rerun the same link and confirm that requested symbol is resolved. If LINK progresses to duplicate-symbol, machine-type, runtime-library or another diagnostic, stop treating it as the original LNK2019.

Fix #4 — a definition exists, but it is not the same linker symbol

C++ name decoration encodes information about a function. A declaration/definition mismatch can therefore compile in separate translation units yet fail to link. Compare the declaration and definition exactly: namespace and class scope, parameter types/order, const/ref qualifiers where applicable, calling convention, and template parameters/instantiations.

Verify: After correcting the mismatch, inspect/rebuild the defining artifact and confirm it now emits the symbol requested by the caller.

Fix #5 — template or static member was declared but never emitted

Templates are a common LNK2019 trap because the compiler generally needs the template definition where it instantiates a specialization. A declaration in a header plus a template definition hidden in an unrelated .cpp may compile callers but leave the required specialization unavailable to the linker. Keep the definition visible to the instantiating translation unit, or explicitly instantiate the specializations you intentionally provide from a source file.

Static data members have a related ownership question: depending on the C++ form and language version, a declaration may not by itself provide the definition/storage your program odr-uses. Check the exact declaration form instead of adding a library blindly.

Verify: Identify the exact template specialization/static member named by LNK2019 and prove that one linked object emits its matching symbol.

Fix #6 — C/C++ linkage, DLL import/export or decorated-name mismatch

If C code is consumed from C++, make the linkage contract explicit where appropriate with extern "C". For a normal MSVC DLL import, the executable links against the DLL's import library (typically a .lib); the DLL itself is needed when the program loads/runs. Keep the two pieces of evidence separate: the DLL must export the intended API, while the import library consumed by this build must provide the matching import symbol/linker contract. Seeing an export in the DLL alone does not prove the correct import library is on the active link.

Do not add extern "C" indiscriminately to C++ APIs. It changes language linkage/name decoration and is appropriate only when the interface contract requires C linkage. Likewise, copying a DLL next to the executable does not resolve a link-time LNK2019 when the required import-library/linker input is absent.

Verify: use DUMPBIN on the relevant object/static library/import library and, separately when applicable, the DLL exports. Compare the exact decorated requested/emitted/import symbols; use UNDNAME only as a readability aid. Then prove the active link consumes the matching import/static-library artifact.

Fix #7 — only one architecture or configuration fails

If Debug works but Release fails—or x86 works but x64 fails—treat that difference as evidence. Libraries and objects must match the target architecture; a machine-type incompatibility may also surface as LNK1112 rather than LNK2019, so preserve companion linker errors instead of forcing every architecture failure into this guide. Visual Studio properties can differ by configuration/platform. Inspect the failing combination's effective Additional Dependencies, library directories, project references, preprocessor/export macros and toolset.

Verify: Clean/rebuild the failing configuration and confirm LINK receives an artifact built for the same target architecture/configuration and resolves the symbol.

When the symbol is opaque: inspect the linker evidence

Microsoft recommends linker diagnostics rather than guessing. /VERBOSE can show linker progress and library/search details; DUMPBIN /SYMBOLS can inspect COFF symbols in objects/libraries, while /EXPORTS shows DLL/executable exports. UNDNAME can translate decorated C++ names into a more readable form.

Important: seeing a readable function name somewhere is not enough. Compare the actual decorated symbol and its ownership. Optimized/LTCG/COMDAT builds can also change what is emitted or retained, so use the artifact from the failing configuration, not a Debug object or stale library from another build. The final proof is that LINK resolves the exact requested symbol in the exact failing link.

Verify: You can now answer one concrete question: definition absent, artifact not linked, or emitted symbol different from requested symbol.

Still seeing LNK2019?

Preserve the first unresolved-symbol line and its caller. If many errors share one library/namespace prefix, investigate that common owner before treating each symbol as an unrelated problem.

Official references