Unresolved External Symbols in complex library dependent project using WINAPI

Question

Having searched for days now i decided to post a question here and hope that somebody has the ultimate idea or advice.

I wrote a WINAPI wrapping mechanism consisting of a WindowManager and a WINAPIWindow class. The latter uses the famous "First WINAPI Window" functionality known from most tutorials in a more structured manner, mainly HWND and HINSTANCE. Remarks: the macro "_ WINDOWS _" (without spaces but this tool makes it bold otherwise ) is a macro defined in one of my headers to determine, wether the compilation environment supports WIN32 and the WINAPI.

#if defined(_ _WINDOWS_ _)

LRESULT CALLBACK gDefaultWndProcFwd(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam);

#pragma region WINAPIWindow

class WINAPIWindow : public WindowBase
{
    friend class WindowManager;

public:
    virtual ~WINAPIWindow();

    RESULT show();

    inline HWND handle() const;

    LRESULT CALLBACK wndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam);

private:
    WINAPIWindow(__in const HINSTANCE hInstance, __in const Rect& bounds, __in const String& title = "", __in const int flags = WDF_DEFAULT);
    HRESULT createWindowClass(__in const HINSTANCE hInstance, __in const String& clsName);

    tInt16 _wndState;
    HWND _hWnd;
};

typedef WINAPIWindow Window;

#pragma endregion
#elif

The mechanism is located in a static library called "ShirabePlatformFeatureLayer.lib". This static library uses classes and code from another custom static lib called "ShiCore.lib" which does not use any platform dependent code.

My actual application project (x64!) now imports both as additional depenencies using the WindowManager.

Although both library projects compile fine and without errors, compiling the Application Project leads to the following error messages.

Error   43  error LNK2019: unresolved external symbol "public: struct HWND__ * __cdecl ShirabePlatformFeatureLayer::WINAPIWindow::handle(void)const " (?handle@WINAPIWindow@ShirabePlatformFeatureLayer@@QEBAPEAUHWND__@@XZ) referenced in function wWinMain    C:\Users\Dev.Dev-PC\Documents\Workspaces\ShirabeEngine\ShirabeDevelopment\Win32TestProject\main.obj Win32TestProject
Error   45  error LNK2019: unresolved external symbol "__int64 __cdecl ShirabePlatformFeatureLayer::gDefaultWndProcFwd(struct HWND__ *,unsigned int,unsigned __int64,__int64)" (?gDefaultWndProcFwd@ShirabePlatformFeatureLayer@@YA_JPEAUHWND__@@I_K_J@Z) referenced in function "private: long __cdecl ShirabePlatformFeatureLayer::WINAPIWindow::createWindowClass(struct HINSTANCE__ * const,class ShirabeCORE::String const &)" (?createWindowClass@WINAPIWindow@ShirabePlatformFeatureLayer@@AEAAJQEAUHINSTANCE__@@AEBVString@ShirabeCORE@@@Z) C:\Users\Dev.Dev-PC\Documents\Workspaces\ShirabeEngine\ShirabeDevelopment\Win32TestProject\ShirabePlatformFeatureLayer.lib(Window.obj)  Win32TestProject
Error   44  error LNK2001: unresolved external symbol "public: struct HWND__ * __cdecl ShirabePlatformFeatureLayer::WINAPIWindow::handle(void)const " (?handle@WINAPIWindow@ShirabePlatformFeatureLayer@@QEBAPEAUHWND__@@XZ)    C:\Users\Dev.Dev-PC\Documents\Workspaces\ShirabeEngine\ShirabeDevelopment\Win32TestProject\ShirabePlatformFeatureLayer.lib(WindowManager.obj)   Win32TestProject
Error   46  error LNK1120: 2 unresolved externals   C:\Users\Dev.Dev-PC\Documents\Workspaces\ShirabeEngine\ShirabeDevelopment\Debug\Win32TestProject.exe    Win32TestProject

I checked, whether the methods are declared and defined properly. I also included and imported the libs.

#if defined(_ _WINDOWS_ _)

#pragma comment(lib, "user32.lib")
#pragma comment(lib, "kernel32.lib")
#pragma comment(lib, "gdi32.lib")
#include <Windows.h>

#endif

In addition i registered the 3 libs above as additional dependencies and the lib-directories are $(VC_LibraryPath_x64) and $(WindowsSDK_LibraryPath_x64).

My first thoughts after having analyzed this a bit is, that all methods or functions that use WINAPI classes and structs are not linked into the import library "ShirabePlatformFeatureLayer.lib". Having registered them above 3 libs as additional dependencies with equal library paths as above and the /VERBOSE:LIB shows me that the libraries are appended but not with "x64\gdi32.lib" as the message but "GDI32.DLL". Likewise for the other two.

Doing /VERBOSE:LIB in the application project shows me the actual relative paths to the "~.lib" and not "~.DLL".

What can cause the methods to not being linked/included/important when they use WINAPI functionality? Is the general build design with so many .libs the problem? Does anybody else have an idea?

Here the entire affected code ( imho ): http://pastebin.com/f7MaBBwM

If any further information is required, please tell me.

EDIT: I've continued searching and came up with the "project to project" dependencies in the new MSBuild system. Although this appeared to be the same problem, it isn't since obviously the dependency of "ShirabePlatformFeatureLayer.lib" to the import libs kernel32, gdi32 and user32 causes problem, when effectively being consumed by the Win32TestProject using the ShirabePlatformFeatureLayer.lib code.

Unfortunately i wasn't able to solve the problem yet with the various advice given est. 10 different articles on the topic. :/

Edit: Consulting Rodrigo s remarks i was able to get rid of the handle() unresolved symbol. However the second with gDefaultWndProcFwd seems to be a logic/design error.

Once i managed to get 10 Reputation I'll attach an image of the relation between WindowManager, WINAPIWindow and gDefaultWndProcFwd! That said here a textual description:

1) Creating the window implies creating the WindowClassEx structure that refers to gDefaultWndProcFwd using a forward declaration in Window.h.

2) When the window is created and shown the method should be called, which consults WIndowManager::get(key : HWND) : WindowBase*;

3) If found, the function invokes wndProc on the window pointer and leaves handling to the specified implementation of the wndproc.

The gDefaultWndProcFwd is declared and defined in WindowManager.h/.cpp.

The design flaw becomes more and more obvious, as I'm thinking about a solution! See the pastebin link for the actual code!

Thank you very much for your help in advance.

Sincerely, Marc

rodrigo · Accepted Answer · 2014-06-19T10:58:51.533

1

You have 2 unresolved external symbols:

HWND ShirabePlatformFeatureLayer::WINAPIWindow::handle(void) const
LRESULT ShirabePlatformFeatureLayer::gDefaultWndProcFwd(HWND,UINT,WPARAM,LPARAM)

The first one is probably due to handle() being inline. You probably defined it in the CPP file (or you forgot it?) , but since it is inline, the definition is not exported. Instead it is expected to be available to every compilation unit that needs it. In other words, inline functions should be defined in the same header file as the declaration.

The second one is trickier without seeing all your code. But I'd bet that you simply forgot to write the defintion of gDefaultWndProcFwd(). Or maybe you wrote it in a different namespace, or with different parameters.

Note that static libraries are not linked, so unresolved symbol errors such as yours, will never happen when building the library, even when the defect is in the library itself. Linker errors will always happen when linking the final executable.

UPDATE: Ok, I said it was tricky... Re-reading your code I noticed that the offending function is declared twice, and defined once. That itself is not a problem, but look at the two declarations together:

LRESULT CALLBACK gDefaultWndProcFwd(HWND hWnd, UINT msg, LPARAM lParam, WPARAM wParam);
LRESULT CALLBACK gDefaultWndProcFwd(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam);

And the definition is:

LRESULT CALLBACK gDefaultWndProcFwd(HWND hWnd, UINT msg, LPARAM lParam, WPARAM wParam)

Do you see the difference? WPARAM and LPARAM are swapped!!!

edited Jun 19 '14 at 10:58

answered Jun 19 '14 at 10:26

rodrigo

94,151
12
143
190

Hello rodrigo. Thanks for your answer. I'll investigate the inline thing, since the handle() is defined in the cpp and might cause the error. The latter however is really a tricky thing. I've posted a pastebin above where you can see the definition. I've continued investigation on this and think that the problem is wanting to use the func in Window.cpp and forward declare it in Window.h. The function itself however is declared and defined in WindowManager.h/.cpp. I think this will leave the actual function undefined for the Window.cpp. I'm going to review and report. Thank you very much. – MABVT Jun 19 '14 at 10:27
And thank you very much for the explanation of how static libs are treated ( or not ) by the linker! – MABVT Jun 19 '14 at 10:32
Report: The first unresolved is gone putting the definition of handle() in the header! :) – MABVT Jun 19 '14 at 10:49
@MABVT: I think I've solved the second case. Please, see my updated answer. – rodrigo Jun 19 '14 at 11:03
Hello rodrigo, I reviewed the thing and corrected the signatures. In addition, however, since the forward decl. was in the global namespace I had to move the definition up into the according one. The window class creation works fine now, although the window itself cannot be created. This however is another case. It works now and I'll mark your answer as correct! Thank you very much! – MABVT Jun 19 '14 at 11:30

Unresolved External Symbols in complex library dependent project using WINAPI

1 Answers1