Sign in to follow this  
Mantear

Cross platform compiling: problem on Win32

Recommended Posts

Greetings, I'm compiling a code base (C++) under both Win32 and an embedded platform, with the Win32 environment being used as a testbench. I recently ran into issues during linking. Here are the errors:
1>ProjectMessageDispatcher.obj : error LNK2001: unresolved external symbol "public: virtual class MSGlib::Message * __thiscall MSGlib::MessageHandler::GetMessageW(void)" (?GetMessageW@MessageHandler@MSGlib@@UAEPAVMessage@2@XZ)
1>ProjectMessageDispatcher.obj : error LNK2001: unresolved external symbol "public: virtual long __thiscall MSGlib::MessageHandler::SendMessageW(unsigned long,class MSGlib::Message *)" (?SendMessageW@MessageHandler@MSGlib@@UAEJKPAVMessage@2@@Z)
The project uses a MSGlib library, which provides a platform agnostic messaging system. The MessageDispatcher class in the library inherits from a MessageHandler class which provides public virtual GetMessage() and SendMessage() methods. I had no problems with that. However, I need to modify the behavior of the MessageDispatcher, and create a ProjectMessageDispatcher class, (outside of the library), that over-rides a different virtual member method. After doing that, the above errors showed up under MSVC2008. The embedded platform compiles it fine. I can see that it's somehow confusing SendMessage() and GetMessage() with the Win32 version. If I hover over the declaration of GetMessage() in the base class, Intellisense pops up
#define GetMessage GetMessageW
, which is where I think the screw up is happening. I'm not sure how to work around that, though. Everything is already dividing into various namespaces, so I don't understand how it's getting confused.

Share this post


Link to post
Share on other sites
If you are in your own class calling your overriden function GetMessage try to call it using "this->" or by writing the class name as namespace MyClass::GetMessage. This would result in the correct function calls. However, I doubt that this is the problem with the missing implementation error for which I have no idea at the moment.

Share this post


Link to post
Share on other sites
Your problem is that the Windows headers have a line which goes something like this:

#define GetMessage GetMessageW

In non unicode builds it would be defined to be GetMessageA instead. The same goes for SendMessage.

What's causing the link error is that you're including the Windows headers in one module (that's also including your MSGLib header file), but not in the MSGLib cpp file. That means the defines get applied in one place but not another, causing link problems. Possible solutions:

- Include the windows headers everywhere, so it gets renamed everywhere.
- Rename your function so it doesn't share it's name with a standard Windows function.

Share this post


Link to post
Share on other sites
I'm not sure how safe this is, but it seems to be working. In the base class that first declares the virtual GetMessage() and SetMessage(), I put
#ifdef WIN32_SUPPORT // Various *_SUPPORT defined for different platforms.
// Undo the #define *Message *Message* from windows.h
#define GetMessageW GetMessage
#define SendMessageW SendMessage
#define GetMessageA GetMessage
#define SendMessageA SendMessage
#endif // WIN32_SUPPORT

This seems a bit "bad", but like I said, it seems to work. Are there any pitfalls to doing it this way?

Share this post


Link to post
Share on other sites
I'd just do:

#ifdef WIN32_SUPPORT
#include <Windows.h>
#endif // WIN32_SUPPORT

Doing it that way means you won't cause any problems with calls to the actual Windows functions.

It will work correctly if extra problematic functions appear in a new Windows SDK, or are added to your class.

If you really want to remove the defines instead use #undef

[Edited by - Adam_42 on September 8, 2009 11:05:44 AM]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this