I am working on a very large project that has several Visual Studio projects. These projects are built as static libraries and included in the Main project, let’s call it Main.exe.
I have created a new project and built it as a static library, let’s call it MyProj.lib. This library is dependent upon another static library, let’s call it API.lib.
Now, I need to link my project to the Main project. Currently I have both of the static libraries linked to the Main project. I previously asked this question: Link static library in another static library and found out that I can’t nest the static libraries. Paul Michalik pointed out that I need to simply link the two libraries independently when I build the Main project.
I now get several LNK2019 errors from the MyProj.lib library, saying that it can’t find the symbols that are defined in the API.lib library. Visual Studio knows where both of the library files are, so this is very confusing to me. Any ideas?
This kind of confusion stems from the mistaken believe that .lib files are somehow magical. That a linker could see that a .lib file has other dependencies. That is just not the case, a static .lib is just a bag of .obj files. A way to collect compiler output into a single file. Nothing more, nothing less.
What is especially confusing about it is that when you build the library, it will never complain about missing dependencies. The explanation for that is simple, building a library does not run the linker. Just the lib.exe tool that collects the .obj files into a bag.
It doesn’t come together until you actually run the linker to build the final executable. Now all the pieces have to come together, the linker has to also see the .obj or .lib file that contains the dependencies. It complains when it doesn’t.
That’s a very weak link in the C/C++ build model, hard to fix. Vendors have tried to address this, Microsoft did too. They added the non-standard #pragma comment(lib, “something.lib”) feature to tell the linker that it needs to link “something.iib” without you explicitly specifying it in the linker’s Additional Dependencies setting. Very nice. Dealing with exactly where “something.lib” is stored is however a problem you need to deal with. Crud. Another setting.