   C++ Unresolved External Symbol
  Yes I'm having this age old problem again.I'm writing a simple game engine for kicks, and the structure of it at the moment is:Core.lib - Static library with classes like Vector3, Matrix, Quaternion, etcOSLayer.lib - Static library which wraps around OS specific stuff like filesRendererInterface.lib - Static library providing interface that the renderer will implementRenderer.dll - DLL loaded at runtime with a function which returns an object which implements the interface defined in RendererInterfaceEngine.dll - Intended to merge Core.lib, OSLayer.lib, and RendererInterface.lib, plus some more functionalityI've been writing a test application which uses the engine since day one, it's linked with Engine.lib, and has worked up until now. All of a sudden when I'm trying to test my Matrix class (defined in Core.lib) I get unresolved external references.1>Main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: float & __thiscall Engine::Matrix4x4::operator[](int)" (__imp_??AMatrix4x4@Engine@@QAEAAMH@Z) referenced in function _main1>Main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall Engine::Matrix4x4::Matrix4x4(void)" (__imp_??0Matrix4x4@Engine@@QAE@XZ) referenced in function _main1>D:\My Dropbox\programming\Engine\Debug\Testbed.exe : fatal error LNK1120: 2 unresolved externalsIn Engine.h, it includes Core.h, which in turn includes Matrix.h, which was all I thought I needed to do to get Engine.dll to include the implementation of Matrix. I managed to make these errors go away by adding a member variable of type Matrix to a random class in Engine.h, is it normal to have to include "dummy" classes to force a dll to merge a lib into it?Sorry for the essay! Any help would be appreciated.ThanksJoe   
  How are you evoking the compiler?It sounds like Core isn't getting built into Engine.dll.  Merely including Core's headers in Engine will only allow Engine to use Core (but Core must still be linked separately).  Or you can archive both into a single static library (and just link the library as a whole if you want to build it into your final program).  Or you can build both into a dynamic library (which is what I think you are trying to do) -- but you must ensure that both Engine and Core sources are being built in, not merely the headers!   ;Quote:Original post by Gamer GamesterHow are you evoking the compiler?It sounds like Core isn't getting built into Engine.dll.  Merely including Core's headers in Engine will only allow Engine to use Core (but Core must still be linked separately).  Or you can archive both into a single static library (and just link the library as a whole if you want to build it into your final program).  Or you can build both into a dynamic library (which is what I think you are trying to do) -- but you must ensure that both Engine and Core sources are being built in, not merely the headers!Thanks for the reply =)Indeed I am trying to build both into a dynamic library, and broke the Engine up into a few static libraries purely for the sake of making things a little less cluttered during development.How can I get Visual C++ to build Core into the Engine dll? I guess if all else fails I could not bother with the static libs and just have all the code in one project, but I'd rather not if I can help it.CheersJoe   ;  Sorry to bump, but can anyone give me any pointers on how to get my dll to merge in the static libs that its linked with?CheersJoe   ;  From what you've described, is it safe for me to assume that you aren't actually USING any of Core.lib inside of Engine.dll's code, but rather you just want to add that functionality included in Core.lib to your Engine library when you build it?If that's the case, I'm no professional and can't speak with any certainty on the matter, but it sounds like for optimization purposes or something similar the linker is recognizing that while you're including Core.h in your Engine code, it's not actually being used at all and therefore is being left out of the build. That would explain why the dummy variable solves the problem as well.Maybe someone else can comment on linker-time optimizations such as this (I assume you're using VS?). Otherwise, I don't see a whole lot of harm in using a dummy variable as long as it's not too heavy of a resource. Then again there could be another completely valid way to achieve the same result, sorry I can't help you more on the matter.As a last thought, if Core.lib contains Vector3, Matrix, Quaternion, etc. and you want to include that functionality in Engine.dll, how is the main engine library itself NOT making use of those classes at all? I feel like a library such as "Core" would contain some sort of functionality that the Engine would desire. Maybe you should restructure those libraries, or maybe you just haven't gotten to the point in development yet where that connection is established between the two. In that case I really don't see any harm in a (temporary) dummy variable.Hope this helps!   ;Quote:Original post by ChugginWindexFrom what you've described, is it safe for me to assume that you aren't actually USING any of Core.lib inside of Engine.dll's code, but rather you just want to add that functionality included in Core.lib to your Engine library when you build it?If that's the case, I'm no professional and can't speak with any certainty on the matter, but it sounds like for optimization purposes or something similar the linker is recognizing that while you're including Core.h in your Engine code, it's not actually being used at all and therefore is being left out of the build. That would explain why the dummy variable solves the problem as well.Maybe someone else can comment on linker-time optimizations such as this (I assume you're using VS?). Otherwise, I don't see a whole lot of harm in using a dummy variable as long as it's not too heavy of a resource. Then again there could be another completely valid way to achieve the same result, sorry I can't help you more on the matter.As a last thought, if Core.lib contains Vector3, Matrix, Quaternion, etc. and you want to include that functionality in Engine.dll, how is the main engine library itself NOT making use of those classes at all? I feel like a library such as "Core" would contain some sort of functionality that the Engine would desire. Maybe you should restructure those libraries, or maybe you just haven't gotten to the point in development yet where that connection is established between the two. In that case I really don't see any harm in a (temporary) dummy variable.Hope this helps!Thanks for replying =)Well I'm currently using some of the stuff in Core.lib, but not all of it. As you say, it's because at this stage the stuff in Engine.dll isn't yet using all of the stuff in Core.lib. I know this won't be a problem later, but I thought it would be worth addressing..   ;  So wait, your Engine.dll is using other parts of Core.lib, yet you cannot use the Matrix class it holds in your Engine dll unless you use a dummy variable??That is very strange, I don't know enough to say that a static library CAN'T be partially linked into another binary, but it sure does seem strange...I'd just stick with using the dummy variable to get that part of the library included in your Engine, once you're at the point where Engine.dll is actually using the Matrix4x4 class itself you shouldn't have any more problems.   ;Quote:Original post by ChugginWindexSo wait, your Engine.dll is using other parts of Core.lib, yet you cannot use the Matrix class it holds in your Engine dll unless you use a dummy variable??That is very strange, I don't know enough to say that a static library CAN'T be partially linked into another binary, but it sure does seem strange...I'd just stick with using the dummy variable to get that part of the library included in your Engine, once you're at the point where Engine.dll is actually using the Matrix4x4 class itself you shouldn't have any more problems.I can use the Matrix class from Core.lib in Engine.dll, it's just that I'm not (yet). I just can't use it in an application which uses Engine.dll unless there's that dummy variable there, or I start using Matrix in the code for Engine.dll. Hope that makes sense!   ;  Ya I understand what you're saying, I'm just confused. Because that means that the parts of Core.lib that you ARE using in Engine.dll are being linked into it when you build the binaries, yet the parts you aren't using yet (i.e. Matrix4x4) are not being linked in...I just always thought that if you referenced any part of a library, that whole library got linked in. Sort of an "all or none" thing.   ;  Indeed.. What I really need is some kind of compiler expert to reply to this topic.. =D   