When inheriting from a class with the same filename that resides in a different lib the linker yields an unresolved external symbol error. Think of this inheritance: LIB2::MyClass : public LIB1::MyClass.
static lib “lib1”:
MyClass.h:
namespace LIB1
{
class MyClass
{
public:
MyClass();
~MyClass();
};
}
static lib “lib2”:
MyClass.h:
#include "..\MyClass.h" // Header of MyClass from lib1 somewhere else than this header file
namespace LIB2
{
class MyClass : public LIB1::MyClass
{
public:
MyClass();
~MyClass();
};
}
Let’s assume both .cpp files exist.
lib2 links in lib1
Some executable then tries to link in lib2 and use the derived MyClass, say
#include "\lib2\MyClass.h"
int main()
{
LIB2::MyClass c;
}
Linking fails with
error LNK2001: unresolved external symbol “public: __thiscall LIB1::MyClass::~MyClass(void)
(same for ctor)
When I simply change the file name of one of the MyClass.cpp to MyClass1.cpp everything is fine.
Instead of searching the definitions for LIB1:MyClass in lib1.lib the linker tries to find them in MyClass.obj (from lib2) I suspect.
This behaviour just feels way too strange to be intentionally. What am I missing?
Furthermore when setting up a solution in VS2005/2010 including both the libs and the executable and having VS set up all lib dependencies through Project Properties->Common Properties->Framework and References (instead of supplying paths to the libs in the linker settings) linking succeeds.
I just made a solution in Microsoft Visual C++ 2010 Express containing two static library projects (lib1 and lib2) and an application project (main) with the contents that you describe and was able to reproduce your problem. Here is the complete build output I get:
The message “Replacing Debug\MyClass.obj” sheds some light on the issue. This message was emitted by Microsoft’s Library Manager (LIB.EXE) while building lib2.lib. In order to understand this message, it is important to understand exactly what a static library file (.lib) is, and by extension, exactly what LIB.EXE does.
First thing’s first: no code is actually linked when building a static library. A .lib file is just an archive that contains one or more .obj files inside of it. In other words, the purpose of a .lib file is to provide a convenient way to distribute a collection of .obj files as one file. All that LIB.EXE does is package up the project’s .obj files into a .lib file. LIB.EXE also has options for doing other stuff with .lib files, such as listing all of the contained .obj files and extracting them; see MSDN for more info.
Your question states that “lib2 links in lib1.” I’m assuming this means that you put lib1.lib as an “Additional Dependency” in lib2’s project settings, as shown in this screenshot:
In order to understand exactly what adding a .lib file as an “Additional Dependency” of a static library project like this does, after changing this setting, I followed the procedure in this answer to see the command-line that is used when running LIB.EXE to build lib2.lib. Here is is:
This command produces a new static library file named lib2.lib that contains all of the .obj files in lib1.lib, as well as MyClass.obj. The fact that lib1.lib also contains an object named MyClass.obj is the source of your problem. As is stated in LIB.EXE’s documentation on MSDN:
The message “Replacing Debug\MyClass.obj” is printed to the console when LIB.EXE sees the second instance of MyClass.obj because it thinks that the second MyClass.obj is supposed to replace the first one. Renaming one of the MyClass.cpp files to MyClass1.cpp fixes this problem because there are no longer two object files named MyClass.obj, so both of them can live happily together in the same .lib file.
It seems that you’ve already come up with some workarounds for this, but hopefully you now understand the behavior that you’re seeing.