Archived

This topic is now archived and is closed to further replies.

squicklid

Unresolved Externals

Recommended Posts

The creation of an executable from C++ source code is done in two steps : compilation and linking.

The compiler turns .cpp files into .obj files. There is an .obj file created for each .cpp one. This is where you get "compiler errors", the error number starts with a "C" for these. Like C1004 for instance.

Then, the linker links all .obj files (along with additional .lib) files together into an executable. This is where you get linking errors, starting with "L", for instance L2001.

The linking step is necessary, because every .obj file needs stuff that''s needed in other .obj files : the linker finds that required stuff, and glues it all together.

You usually write in one of your source files that you need a specific object that is not defined in the same source file (say, Direct3DCreate9() ) : this is called an external. This is a perfectly correct and compilable C++ command, because the compiler merely states "Hey, Linker! Find that object for me!". When you compile that source file, the .obj that is created will mention the required object (a weird name with @''s inside it). The linker will then attempt to find it in the other .obj files or any .lib files you have told it to use. If it doesn''t find the required object, then it can''t build the executable, and throws an errer : it could not "resolve" (find) the required object. The weird name comes from the fact that the linker did not read the source code, only the .obj file.

Victor Nicollet, INT13 game programmer

Share this post


Link to post
Share on other sites
Thanks. I was just wondering because this seems to happen when there is nothing wrong with the #includes.. but I usually fudge it to make it work.

Share this post


Link to post
Share on other sites