Specifications

Linker Tools Messages Page 14 of 32
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 located in the Online Information
System for more information. An easy way to reach an article is to copy a "Q" number above,
open the Search dialog box from the Help menu and select the Query tab, then paste the number
into the first text box and press ENTER.
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 reference
"__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: