{"id":3848,"date":"2022-08-20T19:47:59","date_gmt":"2022-08-20T14:17:59","guid":{"rendered":"https:\/\/jassweb.com\/solved\/solved-what-is-an-undefined-reference-unresolved-external-symbol-error-and-how-do-i-fix-it\/"},"modified":"2022-08-20T19:47:59","modified_gmt":"2022-08-20T14:17:59","slug":"solved-what-is-an-undefined-reference-unresolved-external-symbol-error-and-how-do-i-fix-it","status":"publish","type":"post","link":"https:\/\/jassweb.com\/solved\/solved-what-is-an-undefined-reference-unresolved-external-symbol-error-and-how-do-i-fix-it\/","title":{"rendered":"(Solved) What is an undefined reference\/unresolved external symbol error and how do I fix it?"},"content":{"rendered":"

[ad_1]
\n<\/p>\n

\n
\n
<\/div>\n
\n
\n

Compiling a C++ program takes place in several steps, as specified by 2.2<\/strong> (credits to Keith Thompson for the reference):<\/p>\n

\n

The precedence among the syntax rules of translation is specified by the following phases [see footnote]<\/em>.<\/p>\n

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

    [footnote]<\/em> Implementations must behave as if these separate phases occur, although in practice different phases might be folded together.<\/p>\n<\/blockquote>\n

    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.<\/p>\n

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

    If you’re using Microsoft Visual Studio, you’ll see that projects generate .lib<\/code> 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<\/code> (if any).<\/p>\n

    Similar mechanisms exist for other compilers\/ platforms.<\/p>\n

    Common error messages are error LNK2001<\/code>, error LNK1120<\/code>, error LNK2019<\/code> for Microsoft Visual Studio<\/strong> and undefined reference to<\/code> symbolName<\/em> for GCC<\/strong>.<\/p>\n

    The code:<\/p>\n

    struct X\n{\n   virtual void foo();\n};\nstruct Y : X\n{\n   void foo() {}\n};\nstruct A\n{\n   virtual ~A() = 0;\n};\nstruct B: A\n{\n   virtual ~B(){}\n};\nextern int x;\nvoid foo();\nint main()\n{\n   x = 0;\n   foo();\n   Y y;\n   B b;\n}\n<\/code><\/pre>\n
    will generate the following errors with GCC<\/strong>:<\/p>\n
    \/home\/AbiSfw\/ccvvuHoX.o: In function `main':\nprog.cpp:(.text+0x10): undefined reference to `x'\nprog.cpp:(.text+0x19): undefined reference to `foo()'\nprog.cpp:(.text+0x2d): undefined reference to `A::~A()'\n\/home\/AbiSfw\/ccvvuHoX.o: In function `B::~B()':\nprog.cpp:(.text._ZN1BD1Ev[B::~B()]+0xb): undefined reference to `A::~A()'\n\/home\/AbiSfw\/ccvvuHoX.o: In function `B::~B()':\nprog.cpp:(.text._ZN1BD0Ev[B::~B()]+0x12): undefined reference to `A::~A()'\n\/home\/AbiSfw\/ccvvuHoX.o:(.rodata._ZTI1Y[typeinfo for Y]+0x8): undefined reference to `typeinfo for X'\n\/home\/AbiSfw\/ccvvuHoX.o:(.rodata._ZTI1B[typeinfo for B]+0x8): undefined reference to `typeinfo for A'\ncollect2: ld returned 1 exit status\n<\/code><\/pre>\n
    and similar errors with Microsoft Visual Studio<\/strong>:<\/p>\n
    1>test2.obj : error LNK2001: unresolved external symbol \"void __cdecl foo(void)\" (?foo@@YAXXZ)\n1>test2.obj : error LNK2001: unresolved external symbol \"int x\" (?x@@3HA)\n1>test2.obj : error LNK2001: unresolved external symbol \"public: virtual __thiscall A::~A(void)\" (??1A@@UAE@XZ)\n1>test2.obj : error LNK2001: unresolved external symbol \"public: virtual void __thiscall X::foo(void)\" (?foo@X@@UAEXXZ)\n1>...\\test2.exe : fatal error LNK1120: 4 unresolved externals\n<\/code><\/pre>\n
    Common causes include:<\/p>\n