linker issue function unresolved referenced in WinMain

Started by
2 comments, last by fanaticlatic 11 years, 7 months ago

Hi all,

I am starting to write a cross-platform engine in C++ using the Visual Studio 2010 Express IDE. Currently at the early stage of trying to get the project hierarchy correct etc.

Starting with windows x86 for now I have hit a linker issue that has got me stumped. Linker issues normally are a case of a lib or include file not being present or up to date, so thats the first thing I checked and everything seems to be ok to me?

The solution to the demo can be found here and it requires the windows sdk 7.1 to have been installed:
http://www.sendspace.com/file/x82ils

From my own experience I can't see where I am going wrong and I am wondering if there is some weirdness going on with WinMain and/or VS Express that would prevent the WinMain call in the application from linking to the public function CoreInit in the Core static library.

On a seperate point I would Ideally like to drop the WinMain call into the Core library rather than have platform specific stuff in the Application project. From what I have read this is possible by defining the /Entry in the VS project settings although I am not sure what this should be set as, for the Core static lib or the Application or both.

Any advice or help anyone can provide would be greatly appreciated smile.png

MarkH.

"I have more fingers in more pies than a leper at a bakery!"
Advertisement

On a seperate point I would Ideally like to drop the WinMain call into the Core library rather than have platform specific stuff in the Application project. From what I have read this is possible by defining the /Entry in the VS project settings although I am not sure what this should be set as, for the Core static lib or the Application or both.


Personally I think that's a bad idea. What you gain from hiding the entry points in your library is marginal at best, and disruptive at worst.

You'll be taking control away from your users. What if they don't want to instantiate your application framework at the beginning of WinMain? Then they have to modify your library.

It's also going to cause them to have to set strange linker settings on every platform in order to properly link the engine if they decide to create new projects for it manually.

Ideally your WinMain would just be something like this:


int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
Application app.
app.init( hInstance, lpCmdLine );
return app.run();
}


.
With perhaps platform-specific versions of Application::init.

What would you actually gain from hiding this from your users?
I take your point, though I think hiding this from the end user is a good thing. They should only be concentrating on the application not the platform specific bits and pieces.



What would you actually gain from hiding this from your users?

I could hide the platform-specific bits with some #ifdefs wrapped around the winmain and main function definitions. Though I think it would be cleaner to have the winmain and main defined within a static lib that the common runtime then calls via the /Entry option. As I say my problem is understanding what the /Entry value should be i.e. the fully qualified name or just the function name or something else and whether the /Entry option is required for both the static library Core and the Demo application?

It's all a bit of a moot point if I cant figure out this linker issue. I seem to be able to build and run ok when the definition of the CoreInit function is placed within the header file, but it fails at the linker stage when the function is defined within the source file. All in all very frustrating problem.

Thanks for your input.
"I have more fingers in more pies than a leper at a bakery!"
Hi all,

Solved the problem. By defaut VS Express sets the Core libs output directory to be "$(SolutionDir)$(Configuration)\" but as my solution is stored in the demo project it meant all the source linkage was not being picked up! Changing the output directory for all libraries to "$(ProjectDir)$(Configuration)\" got me up and running :)

Thanks all.
"I have more fingers in more pies than a leper at a bakery!"

This topic is closed to new replies.

Advertisement