views:

170

answers:

3

I get this error when trying to link a win32 exe project. I have linked in the lib that contains the code for this method. But still gets an unresolved symbol error.

error LNK2001: unresolved external symbol "public: bool __thiscall SharedJobQueue::AddJobA(class boost::shared_ptr<class domain::Job>)" (?AddJobA@SharedJobQueue@@QAE_NV?$shared_ptr@VJob@domain@@@boost@@@Z)

Why does it say AddJobA with the 'A' at the end. The method is declared as AddJob.

I have looked in the output from 'dumpbin /symbols' and it only contains symbols for AddJob not AddJobA. Why do the compiler add an 'A' to the end of the function name?

+1  A: 

Windows functions may have A or W at the end of a function -- A signifies ASCII and W signifies a Wide fixed size unicode. Your project settings determine which function is used. addJob could have had W at the end if you had unicode enabled for your project..

Hassan Syed
+5  A: 

MS uses macros for the Win32 API to support both Unicode and Ansi builds by suffixing the function names with A or W.
AddJob() is a function in the Win32 API and thus has such a macro - you can #undef AddJob to get rid of your problem.

Georg Fritzsche
+3  A: 

And here we see the problem with macros.

There is nothing wrong with your code per se, the problem is with the windows libraries. There is actually a function called AddJob in the Win32 headers, but not quite... The don't declare an Addjob function, but instead an AddJobA and an AddJobW function, which deal with non-unicode and unicode strings respectively.

The A at the end of your function name is due to a macro defined in the windows header that was defined to deal with unicode. Essentially they'll have something like:

#ifdef UNICODE
#  define AddJob AddJobW
#else
#  define AddJob AddJobA
#endif

This allows people to just use AddJob and the macros will point the function towards the correct unicode/non-unicode function. The problem of course is that the #define affects everything, which is what's happening to your function.

To fix this, you can either #undef AddJob or simply change the name of your function to something that isn't a Win32 function.

Peter Alexander
Is there a list of names already "taken" by the win32 headers using macros? So that I can know what names I should not use.
Joakim Karlsson
Good question. I don't believe there is, but then again I haven't looked. The easiest way to check would be to head over to msdn.microsoft.com and search for the name of the function you want to use to see if it's already in "use".
Peter Alexander
I wouldn't go as far to say that the "macro's are a problem" here. They are used in a constant manner throughout the low-level win32 API.
Hassan Syed
You don't see anything wrong with some completely unrelated and hidden piece of code unintentionally modifying, and breaking your code, leaving no clue as to what happened?
Peter Alexander
There is nothing wrong with macros in general, only with how they are used - e.g. if they are used as intrusively as in the Win32 API.
Georg Fritzsche