Trouble with the .exe / .lib split

buuck · Sep 10th 2012, 4:34pm

I'm trying to write this as clearly as possible without copy/pasting a ton of code.

I like the split in the GCC4 code between a .lib file for the general engine and the .exe for the game-specific information. So I'm recreating it in my own separate project.

My Main.cpp file looks just like TeapotWars.cpp does - it declares a global MainApp object and then calls the equivalent of the GameCode4() function to initialize everything.

Here's where I'm getting stuck. In order to compile the .exe it seems to need to see the definition of the GameCodeApp class in order to properly build the TeapotWarsApp. But when I include the header file for the GameCodeApp class it can't properly link the .exe because it's looking for the body to the InitInstance() function inside the GameCodeApp class, which isn't exposed to the TeapotWarsApp project.

So... I guess my question is, how do I properly link the TeapotWarsApp class? Is it that the .exe project is looking for the .lib file that is built in the GameCode4 project? Because this seems to be building fine. Or is it something else?

Hopefully that was clear - if you need more info let me know!

mholley519 · Sep 10th 2012, 5:55pm

Here is the way that it works, an application (exe) is an executable version of software you create, this must have a main function (which it seems you know already), a static library does not execute but instead is like a library that you link directly into your code at compile time.

Your application is able to include the header files from your library while only having to 'link' to the static library, this is exactly how it sounds, when a function from your library needs to be used it is like grabbing a book off of a shelf and reading it.

With library's 2 things need to happen, which I already sort of mentioned buy to put them in point form.

to use a libary class/function you must include a header with the prototype and/or definition, if it is defined in the header file it is all fine and dandy, the actual source of the function is included directly from the headers, if it is a prototype you are trying to use which is defined in the header, at link time when the library is linked these definitions, which are compiled into the library, are linked to your program.

Make sure that you have both a prototype ie.
void SomeFunc();
from a header file

and make sure you have a definition linked ie.
void SomeFunc()
{
cout << "Something" << endl;
}
in a library that is being linked.

Also it is good practice if you are building both your library and application in the same solution to set the applications dependancies to depend on the library, which will force the library to be built first.

buuck · Sep 10th 2012, 6:04pm

Thanks for the outlook. I'm familiar with the basic information on how .lib files work. What confuses me is that I'm exposing the header for the GameCode4 class to my TeapotWars class, and as far as I can tell I have the GameCode.lib file accessible to my executable, but when I try to compile my TeapotWars program it says that the InitInstance() function in GameCode is an unresolved external symbol. Something isn't linking correctly, though it's all compiling okay.

It's hard to explain without showing four different files, which I may do if I can't figure it out...

Kl1X · Sep 10th 2012, 6:53pm

Unresolved external symbols in my own code usually means I forgot to add the "ClassName::" in front of my implementation of a method.

I'd check for that first.

mholley519 · Sep 10th 2012, 7:51pm

Exactly, just look for the said function in your implementation and see if there is anything out of place.

buuck · Sep 11th 2012, 8:54am

Thanks Kl1X, that was the issue. I forgot to put GameCodeApp:: in front of InitInstance, yet the .lib file was compiling okay. It would throw a problem when it tried to link to the .exe.

Thanks for the info as well, mholley!

mholley519 · Sep 11th 2012, 9:39am

Visual C++ is really *nice* to programmers, G++ would have caught that, in VC++ though if you do not implement a method, however never use it anywhere, it will build properly.

Share