Linker Errors LNK2001 to LNK2014
Linker Tools Error LNK2001
unresolved external symbol "symbol"
Code will generate this error message if it references something
(like a function, variable, or label) that the linker cannot find in
all the libraries and object files it searches. In general, there are
two reasons this error occurs: what the code asks for doesn't exist (the
symbol is spelled incorrectly or uses the wrong case, for example), or
the code asks for the wrong thing (you are using mixed versions of the
libraries; some from one version of the product, others from another version).
Depending on the calling convention used, an at sign (@) and a decimal number may
be appended to the symbol name (see ATTRIBUTES
Properties and Calling Conventions).
Numerous kinds of coding and build errors can cause LNK2001. Several specific
causes are listed below, and some have more detailed explanations.
Coding Problems:
- In Fortran programs, some of the causes of the LNK2001 message
can be one of the following:
- Calling a routine with a different number of arguments
or the wrong argument types than it was declared. If an argument count
mismatch is intentional, then use the Fortran OPTIONAL attribute (an explicit
interface is required), or use !DEC$ ATTRIBUTES C to give the called routine
the C attribute (this must be specified both in the calling routine and in the
called routine). For more information, see the Programmer's Guide
section on mixed-language programming.
- Unresolved references to Visual Fortran library routine names can be caused
by omitting the appropriate USE statement required by that routine.
For example, calling the TRACEBACKQQ routine
requires the USE DFLIB statement and DLGINIT
requires USE DFLOGM. Similarly, a specific USE statement is
needed to call IMSL routines and a
specific INCLUDE statement is needed
to call CXML routines.
- Unresolved references to _WinMain@16 can be caused by
specifying a project type as Fortran Windows for a
traditional application (Fortran Windows applications require a
WinMain function declaration and interface). In this case, create a
new Fortran project with the correct project type
(such as Fortran Console), copy the files to the new project directory, and
add them to the new project (see Defining Your Project).
- If the routine you are calling is a Win32 API routine,
you may need to specify its library in Link tab, Object/Library modules field in
the Project Settings dialog box (click Settings in the Project menu).
To see which library is required, read the routines description and click on QuickView
in the Platform SDK documentation (see Calling
Win32 Routines and the Visual Fortran Windows Module).
- Mismatched case in your code or module-definition (.DEF) file can cause LNK2001. For example,
if you named a variable "var1" in one C++ source file and tried to access it as "VAR1" in another,
you would receive this error. The solution is to exactly match the case of the symbol in all
references.
- A project that uses function inlining yet defines the functions in a .CPP file rather than
in the header file can cause LNK2001.
- If you are using C++, make sure to use extern "C" when calling a C function from a C++
program. By using extern "C" you force the use of the C naming convention. Be aware of compiler
switches like /Tp or /Tc that force a file to be compiled as a C (/Tc) or C++ (/Tp) file no matter
what the filename extension, or you may get different function names than you expect.
- Attempting to reference functions or data that don't have external linkage causes LNK2001. In
C++, inline functions and const data have internal linkage unless explicitly specified as extern.
- A missing function body or variable will cause LNK2001. Having just a function prototype or
extern declaration will allow the compiler to continue without error, but the linker will not be
able to resolve your call to an address or reference to a variable because there is no function
code or variable space reserved.
- Name decoration incorporates the parameters of a function into the final decorated function
name. Calling a function with parameter types that do not match those in the function declaration
may cause LNK2001.
- Incorrectly included prototypes will cause the compiler to expect a function body that is not
provided. If you have both a class and non-class implementation of a function F, beware of C++
scope-resolution rules.
- When using C++, make sure that you include the implementation of a specific function for a
class and not just a prototype in the class definition.
- Attempting to call a pure virtual function from the constructor or destructor of an abstract
base class will cause LNK2001 since by definition a pure virtual function has no base class
implementation.
- Only global functions and variables are public.
Functions declared with the static modifier by definition have file scope. Static variables
have the same limitation. Trying to access any static variables from outside of the file in which
they are declared can result in a compile error or LNK2001.
A variable declared within a function (a local variable) can only be used within the scope of
that function.
C++ global constants have static linkage. This is different than C. If you try to use a global
constant in C++ in multiple files you get error LNK2001. One alternative is to include the const
initializations in a header file and include that header in your .CPP files when necessary, just as
if it was a function prototype. Another alternative is to make the variable non-constant and use a
constant reference when assessing it.
Compiling and Linking Problems:
- The names of the run-time libraries needed at link time are included in the
object file module by the compiler. If you use the /NOD (/NODEFAULTLIB) option, these
libraries will not be linked into the project unless you have explicitly included them. Using /NOD
will cause error LNK2001 in this case.
- If you are using Unicode and MFC, you will get an unresolved external on _WinMain@16 if you
don't create an entrypoint to wWinMainCRTStartup. Use the /ENTRY option or type this value in the
Project Settings dialog box. (To find this option in the development environment, click Settings on
the Project menu, then click the Link tab, and click Output in the Category box.)
- See the following Microsoft Knowledge Base articles for more information (either search
MSDN if it is installed or use a Web browser to search for the following article Q numbers
at http://support.microsoft.com/support):
- Q125750 "PRB: Error LNK2001: '_WinMain@16': Unresolved External Symbol"
- Q131204 "PRB: Wrong Project Selection Causes LNK2001 on _WinMain@16"
- Q100639 "Unicode Support in the Microsoft Foundation Class Library"
- Linking code compiled with /MT with the library LIBC.LIB causes LNK2001
on _beginthread, _beginthreadex, _endthread, and _endthreadex.
- When compiling with /MD, a reference to "func" in your source becomes a
eference "__imp__func"
in the object since all the run-time is now held within a DLL. If you try to link with the static
libraries LIBC.LIB or LIBCMT.LIB, you will get LNK2001 on __imp__func. If you try to link with
MSVCxx.LIB when compiling without /MD you will not always get LNK2001, but you will likely have
other problems.
- Linking code compiled with an explicit or implicit /ML to the LIBCMT.LIB causes LNK2001
on _errno.
- Linking with the release mode libraries when building a debug version of an application can
cause LNK2001. Similarly, using an /Mxd option (/MLd, /MTd, or /MDd) and/or defining _DEBUG and
then linking with the release libraries will give you potential unresolved externals (among other
problems). Linking a release mode build with the debug libraries will also cause similar problems.
- Mixing versions of Microsoft libraries and compiler products can be problematic. A new compiler
version's libraries may contain new symbols that cannot be found in the libraries included with
previous versions. Use DUMPBIN to find out if a symbol is in a 32-bit object file or library.
- There is currently no standard for C++ naming between compiler vendors or even between
different versions of a compiler. Therefore linking object files compiled with other compilers
may not produce the same naming scheme and thus cause error LNK2001.
- Mixing inline and non-inline compile options on different modules can cause LNK2001. If a
C++ library is created with function inlining turned on (/Ob1 or /Ob2) but the corresponding
header file describing the functions has inlining turned off (no inline keyword), you will get
this error. To prevent this problem, have the inline functions defined with inline in the header
file you are going to include in other files.
- If you are using the Visual C++ #pragma inline_depth compiler directive, make sure you have a
value of 2 or greater set, and make sure you are using the /Ob1 or /Ob2 compiler option.
- Omitting the LINK option /NOENTRY when creating a resource-only DLL will cause LNK2001.
- Using incorrect /SUBSYSTEM or /ENTRY settings can cause LNK2001. For example, if you write a
character-based application (a console application) and specify /SUBSYSTEM:WINDOWS, you will get
an unresolved external for WinMain. For more information on these options and entry points, see
the /SUBSYSTEM and /ENTRY linker options.
Export Problems:
- When you are porting an application from 16 to 32 bits, LNK2001 can occur. The current 32-bit
module-definition (.DEF) file syntax requires that __cdecl, __stdcall, and __fastcall functions
be listed in the EXPORTS section without underscores (undecorated). This differs from the 16-bit
syntax, where they must be listed with underscores (decorated). For more information, see the
description of the EXPORTS section of module-definition files.
- Any export listed in the .DEF file and not found will cause LNK2001. This could be because it
does not exist, is spelled incorrectly, or uses decorated names (.DEF files do not take decorated
names). This error message is followed by fatal error LNK1120.
The following sections give more detailed information on some of the issues
named in the above list.
- Missing function body or variable
Having just a function prototype will allow the compiler to continue without error, but the linker
will not be able to resolve your call to an address because there is no function code or variable
space reserved. You will not see this error until you create an actual call to the function that
the linker must resolve.
- Name decoration
Normally this refers to C++ naming conventions, but it applies to a number of non-C++ cases as well.
C++ by default will use the name of a function, its parameters and its return type when calculating
a name for a function.
Use extern "C" when calling a C function from a C++ program. Extern "C" forces use of the C
naming convention for non-class C++ functions.
Linker Tools Error LNK2003
gp relative fixup to symbol not in .sdata "module"
The /Gt value specified when compiling an instance of a type differed from the value specified when
compiling the reference to the type. Rebuild the object files with consistent values for /Gt. This
error is followed by fatal error LNK1165.
Linker Tools Error LNK2004
gp relative fixup overflow; sdata section ("section") is too large
The .sdata section was too large. Rebuild using smaller values for /Gt.
This error is followed by fatal error LNK1165.
Linker Tools Error LNK2005
symbol already defined in object
The given symbol, displayed in its decorated form, was multiply defined. One of the following may
be a cause:
Linker Tools Error LNK2006
TOC relative fixup to symbol not in TOC "name"; fixup ignored
LINK found an invalid fixup and ignored it.
Linker Tools Error LNK2007
TOC relative fixup overflow; TOC is too large; fixup ignored
LINK found an invalid fixup and ignored it.
Linker Tools Error LNK2008
Fixup target is not aligned "alignment"
LINK found a fixup target in your object file that was not aligned properly.
Linker Tools Error LNK2009
Fixup target must be absolute "name" w/o -FIXED; fixup ignored
LINK found an invalid fixup and ignored it.
Linker Tools Error LNK2010
Duplicate IMGLUE relocations for "name"
LINK found duplicate relocations for "name" in your object file. The object file is probably
corrupt. See Corrupt Object File for more information.
Linker Tools Error LNK2011
precompiled object not linked in; image may not run
If you use precompiled headers, LINK now requires that all of the object files created with
precompiled headers must be linked in. If you have a source file that you use to generate a
precompiled header for use with other source files, you now must include the object file created
along with the precompiled header.
Linker Tools Error LNK2012
No NOP following relocationtype relocation to "symbol"
TOCINDIRCALL and TOCCALLREL require a NOP following the instruction that has this type of
relocation. This is mainly useful for compiler and assembler developers who use
the Microsoft linker.
Linker Tools Error LNK2013
Fixup overflow. Target "symbol" is out of range
This error occurs when the executable is too large or the error may indicate a problem with
assembly code. To work around the problem:
- Use shared libraries.
- TOC space is required for global data accessed from a module other than where it is defined.
You can eliminate the TOC space by moving such data to the module where it is referenced. However,
if data is referenced in multiple modules, then the TOC space cannot be eliminated to save space.
Linker Tools Error LNK2014
TLS relative fixup overflow; .tls section ("section") is too large
The section created for thread-local storage (.tls) is too large. TLS data must fit in 32 KB. This
data is created using the __declspec(thread) storage class modifier in the declaration and
definition of that data. To work around the problem:
- Reduce the amount of thread-local data in the code.
- Use dynamic TLS by calling functions such as TlsAlloc and TlsFree.
Return to Main Linker Error Page