Thread: link2001 errors in my exceptionhandling program

  1. #1

    link2001 errors in my exceptionhandling program

    Can I get help determining how to get around these 19 lnk2001 errors?

    ex:Guarantee_StrongWeakNothrow.obj : error LNK2001: unresolved external symbol __afxForceEXCLUDE


    class GUARANTEE
    int a,b,c,d,e,f,g,h;

    void NoThrowGuarantee();
    void StrongGuarantee();
    void recover();
    void WeakGuarantee();

    int compute(int a , int b);
    int compute1(int c, int d);
    int compute2(int e,int f);

    int undoCompute1(int g,int h);

    #include "Guarantee_StrongWeakNothrow.h"
    #include <iostream.h>//to cin,cout
    #include <iostream>
    #include <afx.h>//to catch exceptions
    //using namespace std; //immediately after all include directives that name the standard headers.

    void main(void)

    GUARANTEE guarantee;

    void GUARANTEE::NoThrowGuarantee()
    {//no exceptions are thrown
    cout << endl << "Just entered NoThrowGuarantee()." << endl;

    void GUARANTEE::StrongGuarantee()
    int a,b,c;
    cout << "Enter a: ";
    cin >> a;
    cout << endl << "Enter b: ";
    cin >> b;
    catch(CException* e )


    void GUARANTEE::WeakGuarantee()
    cout << endl << "Just entered WeakGuarantee()." << endl;


    int GUARANTEE::compute(int a , int b)
    int c;
    int d;
    } catch(CException* e ){

    return (c+d);


    int GUARANTEE::compute1(int c, int d)

    return (c+d);
    int GUARANTEE::compute2(int e,int f)
    return (e*f);

    int GUARANTEE::undoCompute1(int g,int h)
    return (h-g);

    void GUARANTEE::recover()
    cout << endl << "Just entered recover()." << endl;

    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
    can't 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).

    Numerous kinds of coding and build errors can cause LNK2001.
    Several specific causes are listed below, and some have links to
    more detailed explanations.

    Coding Problems

    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
    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 Microsoft run-time and MFC libraries needed at
    link time are included in the object file module by the Microsoft
    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 Build menu, then
    click the Link tab, and click Output in the Category box.) See
    Unicode Programming Summary.

    See the following 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 #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
    Name decoration
    The symbol is not public
    Automatic (function scope) variables
    Global constants in C++
    Function inlining problems

  2. #2
    Registered User
    Join Date
    Nov 2002
    thats quite a bit of info. don't feel like reading all that.
    but from what it looks like from a quick skim, that you are trying to create a console app. you selected win32api, so you provided the wrong main. also, don't use void main. oh, and iostream.h should not be used, to follow standard, and double declaring iostream.h and iostream is bad practice.

    select a new project to console app, that should fix the WinMain errors. It may fix the rest.

    edit: also code tags are wrapped by [ ] not < >

  3. #3
    Registered User
    Join Date
    Feb 2003
    Is __afxForceEXCLUDE a variable you use someplace else in your program?

    I don't see it in the code you posted.

  4. #4
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Probably it's not explicitly used in the code; it could be one of the functions/variables referenced from somewhere "under the hood".
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  5. #5
    Registered User
    Join Date
    Feb 2003
    I think I see it. You have
    #include <afx.h>

    That doesn't look like a standard header.
    If afx.h is your own header file you need to say

    #include "afx.h"

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Program Plan
    By Programmer_P in forum C++ Programming
    Replies: 0
    Last Post: 05-11-2009, 01:42 AM
  2. Need help to solve program errors
    By pattop in forum C++ Programming
    Replies: 6
    Last Post: 05-28-2006, 01:57 AM
  3. mega compile errors for small program
    By s_UNI_ in forum C++ Programming
    Replies: 4
    Last Post: 04-28-2005, 12:00 PM
  4. Errors with program
    By nizbit in forum C Programming
    Replies: 37
    Last Post: 12-19-2004, 09:56 PM
  5. I'm a newbie and I can't understand the errors in my program
    By iluvmyafboys in forum C++ Programming
    Replies: 19
    Last Post: 02-20-2002, 10:40 AM