Unresolved External Symbol in Object Files

Unresolved external symbol in object files

This error often means that some function has a declaration, but not a definition.

Example:

// A.hpp
class A
{
public:
  void myFunc(); // Function declaration
};

// A.cpp

// Function definition
void A::myFunc()
{
  // do stuff
}

In your case, the definition cannot be found. The issue could be that you are including a header file, which brings in some function declarations, but you either:

1. do not define the functions in your cpp file (if you wrote this code yourself)
2. do not include the lib/dll file that contains the definitions

A common mistake is that you define a function as a standalone and forget the class selector, e.g. A::, in your .cpp file:

Wrong: void myFunc() { /* do stuff */ }

Right: void A::myFunc() { /* do stuff */ }

What is an undefined reference/unresolved external symbol error and how do I fix it?

Compiling a C++ program takes place in several steps, as specified by 2.2 (credits to Keith Thompson for the reference):

The precedence among the syntax rules of translation is specified by the following phases [see footnote].

1. Physical source file characters are mapped, in an implementation-defined manner, to the basic source character set
   (introducing new-line characters for end-of-line indicators) if
   necessary. [SNIP]
2. Each instance of a backslash character (\) immediately followed by a new-line character is deleted, splicing physical source lines to
   form logical source lines. [SNIP]
3. The source file is decomposed into preprocessing tokens (2.5) and sequences of white-space characters (including comments). [SNIP]
4. Preprocessing directives are executed, macro invocations are expanded, and _Pragma unary operator expressions are executed. [SNIP]
5. Each source character set member in a character literal or a string literal, as well as each escape sequence and universal-character-name
   in a character literal or a non-raw string literal, is converted to
   the corresponding member of the execution character set; [SNIP]
6. Adjacent string literal tokens are concatenated.
7. White-space characters separating tokens are no longer significant. Each preprocessing token is converted into a token. (2.7). The
   resulting tokens are syntactically and semantically analyzed and
   translated as a translation unit. [SNIP]
8. Translated translation units and instantiation units are combined as follows: [SNIP]
9. All external entity references are resolved. Library components are linked to satisfy external references to entities not defined in the
   current translation. All such translator output is collected into a
   program image which contains information needed for execution in its
   execution environment. (emphasis mine)

[footnote] Implementations must behave as if these separate phases occur, although in practice different phases might be folded together.

The specified errors occur during this last stage of compilation, most commonly referred to as linking. It basically means that you compiled a bunch of implementation files into object files or libraries and now you want to get them to work together.

Say you defined symbol a in a.cpp. Now, b.cpp declared that symbol and used it. Before linking, it simply assumes that that symbol was defined somewhere, but it doesn't yet care where. The linking phase is responsible for finding the symbol and correctly linking it to b.cpp (well, actually to the object or library that uses it).

If you're using Microsoft Visual Studio, you'll see that projects generate .lib files. These contain a table of exported symbols, and a table of imported symbols. The imported symbols are resolved against the libraries you link against, and the exported symbols are provided for the libraries that use that .lib (if any).

Similar mechanisms exist for other compilers/ platforms.

Common error messages are error LNK2001, error LNK1120, error LNK2019 for Microsoft Visual Studio and undefined reference to symbolName for GCC.

The code:

struct X
{
   virtual void foo();
};
struct Y : X
{
   void foo() {}
};
struct A
{
   virtual ~A() = 0;
};
struct B: A
{
   virtual ~B(){}
};
extern int x;
void foo();
int main()
{
   x = 0;
   foo();
   Y y;
   B b;
}

will generate the following errors with GCC:

/home/AbiSfw/ccvvuHoX.o: In function `main':
prog.cpp:(.text+0x10): undefined reference to `x'
prog.cpp:(.text+0x19): undefined reference to `foo()'
prog.cpp:(.text+0x2d): undefined reference to `A::~A()'
/home/AbiSfw/ccvvuHoX.o: In function `B::~B()':
prog.cpp:(.text._ZN1BD1Ev[B::~B()]+0xb): undefined reference to `A::~A()'
/home/AbiSfw/ccvvuHoX.o: In function `B::~B()':
prog.cpp:(.text._ZN1BD0Ev[B::~B()]+0x12): undefined reference to `A::~A()'
/home/AbiSfw/ccvvuHoX.o:(.rodata._ZTI1Y[typeinfo for Y]+0x8): undefined reference to `typeinfo for X'
/home/AbiSfw/ccvvuHoX.o:(.rodata._ZTI1B[typeinfo for B]+0x8): undefined reference to `typeinfo for A'
collect2: ld returned 1 exit status

and similar errors with Microsoft Visual Studio:

1>test2.obj : error LNK2001: unresolved external symbol "void __cdecl foo(void)" (?foo@@YAXXZ)
1>test2.obj : error LNK2001: unresolved external symbol "int x" (?x@@3HA)
1>test2.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall A::~A(void)" (??1A@@UAE@XZ)
1>test2.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall X::foo(void)" (?foo@X@@UAEXXZ)
1>...\test2.exe : fatal error LNK1120: 4 unresolved externals

Common causes include:

• Failure to link against appropriate libraries/object files or compile implementation files
• Declared and undefined variable or function.
• Common issues with class-type members
• Template implementations not visible.
• Symbols were defined in a C program and used in C++ code.
• Incorrectly importing/exporting methods/classes across modules/dll. (MSVS specific)
• Circular library dependency
• undefined reference to `WinMain@16'
• Interdependent library order
• Multiple source files of the same name
• Mistyping or not including the .lib extension when using the #pragma (Microsoft Visual Studio)
• Problems with template friends
• Inconsistent UNICODE definitions
• Missing "extern" in const variable declarations/definitions (C++ only)
• Visual Studio Code not configured for a multiple file project

Unresolved External Symbol while creating an object

I see you did not include AtpReader.h in AtpReader.cpp, but probably you just missed it when you made copy/paste, to insert it here, because if you didn't really include it, the error would have been different. Also, I see you're including in your main.cpp both "atlasobject.h"
and "atp.h" and you don't really need that.

Later edit: Your problem is in the atp.h...you constructor is declared but never defined. Do this: ATP(){};

LNK2019 : unresolved external symbol, searched for in a non-existing *.obj file

Good morning,

I have finally solved my issue. As a good citizen, I will describe how I have done it :-), but as a less good programmer, I need to admit that I don't understand how my actions solve the problem ;-(

I have done a file comparison of both *.vcxproj Visual Project files (the old one from VC2010 and the new VC2013 one). In that way I have seen that the "umultiproc.cpp" entry was missing in the VC2013 one:

<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

...

<ItemGroup>

...

<ClCompile Include="..\..\mp\umultiproc.cpp" /> <!-- missing -->

Summary: In the error message, there was an unresolved symbol (C_Semaphore constructor), which was defined in *.cpp/*.h source/header file. In order to solve the error, I have added a reference to the *.cpp source file into the VC2013 project file.

c++ error LNK2019: unresolved external symbol .obj

In "CommandSyncHandler.cpp", in the definition of the function FileJustRenamed() prepend the class-name CommandSyncHandler to the function name, like this:

std::string CommandSyncHandler::FileJustRenamed(std::string filename){

---

Related Topics