Stubborn Unresolved External Symbol Problem.

Question

Hello Folks:
   Developing on Win8.1 Pro, Visual Studio 2010, C++, WIN32 no MFC.  
   Here is a weird one.  I must be doing something really stupid.  
   I've been adding code to a massive project for years.  It was 100,000 lines of code when I checked a couple of years ago, and is growing.  
   The application's static library has over 200 ".cpp" source files, not counting the headers.  It also relies upon a similar number of source modules from static libraries used by other applications.  
   Yesterday builds started generating this error, formatted to make it easier to understand:
3>tfa.obj : error LNK2019: unresolved external symbol "
bool __cdecl run_contact_import_from_menu(
struct HWND__ *,
struct HWND__ *,
class PROCESS_RECORD *,
class TFA_THREAD_CRYPTO_RECORD *,
class TFA_THREAD_CRYPTO_RECORD *,
class botan_utilities::EAX_CTR_THREAD_CRYPTO_RECORD *,
class TFA_MAIN_WINDOW_CONTEXT *,
class std::basic_string<char,
struct std::char_traits<char>,
class std::allocator<char> > *)"
   I tried a few things.  When I commented out the call to run_contact_import_from_menu() the application built without a problem.  
   I wasn't even working on that part of the application.  
The usual solution:
   I've seen unresolved external symbol errors before of course.  It usually means I've changed the function's arguments without updating the function's forward declaration in a header, and I haven't updated a call to the function elsewhere
in the code.  The first thing I did was copy the interface from the function's definition in a "cpp" file:
bool run_contact_import_from_menu(HWND hdlg,
HWND change_alert_source_window_handle,
PROCESS_RECORD *process_record_ptr,
TFA_THREAD_CRYPTO_RECORD *tfa_thread_crypto_ptr,
TFA_THREAD_CRYPTO_RECORD *tfa_thread_financial_crypto_ptr,
EMAIL_THREAD_CRYPTO_RECORD *tfa_thread_email_crypto_record_ptr,
TFA_MAIN_WINDOW_CONTEXT *main_window_dialog_context_ptr,
std::string *message_string_ptr)
replaced it in the header file, and added a ";" to make it a forward declaration.  
   Same error.  
   EMAIL_THREAD_CRYPTO_RECORD is botan_utilities::EAX_CTR_THREAD_CRYPTO_RECORD:
   From the email thread's header:
      typedef botan_utilities::EAX_CTR_THREAD_CRYPTO_RECORD EMAIL_THREAD_CRYPTO_RECORD;
   For testing, I slapped that typedef in front of the function's forward declaration and the function's definition.  Compiles fine, same link error.  
This seems to be the only unresolved external
   After #ifdef-ing out the call to this function, this application with it's thousands of calls to thousands of different functions built just fine, and ran as expected.  
Is the module's C++ file being processed?
   This function isn't being found in tfa_contact_import.cpp, where it lives.  What happens when I comment out other function definitions in this C++ file?  
   Now I get a whole bunch of "error LNK2019: unresolved external symbol" errors.  Other functions in that file are being referenced, and found.  And missed if they are absent.  
   Is it positional?  run_contact_import_from_menu() is the first function defined in the file.  Moving it to the end of the file gets me the same error.  
   I create a new C++ file with the "Add New Item" to the app's library, just for this function.  Same error.  
   I change the function's name to "run_contact_import_from_menu_x".  New name, same error.  
   I'm missing something really basic, really obvious.  Can someone tell me what it is?  
      Thanks
      Larry

Answer 1

Thanks Igor:
   For some reason my first reply to your post went missing. 
   No problem.  I didn't understand the dumpbin options when I posted it. 
   So now I have an output of dumpbin run with the /SYMBOLS option. 
   It's pages and pages of stuff.  The decorated names I've seen so far seem to be the function names followed by "@" signs and other text, so I think I can identify the functions. 
   The unresolved external function name, "run_contact_import_from_menu" is nowhere to be found in any text of the dumpbin output.  The second function in the source, "populate_individual_contact_import_vector" can be found
at 9 places in the output, as part of these decorated names. 
   Another function in the same .cpp file was also represented in the dumpbin output. 
   I have some obligations tonight.  Tomorrow, Saturday, I'll try to create a stripped down version of the C++ file that I can present as both a source and dumpbin output in a form small enough to show here.  I don't know enough
about dumpbin to predict how successful that effort will be, but I can snip the source to the function interface definitions and return values. 
      Thanks
      Larry