C++ - Can you build one static library into another?

Question

I ran into a strange problem with a Visual Studio 2008 project I was working with recently.

I am trying to compile a new static library that uses functions from another static library. (Let's say Lib1 is my static library project, and Lib2 is the lib file that Lib1 depends on).

I am able to build lib1 without issue; It includes the header files for lib2 and calls its functions, and there are no problems.

The problem is when I build a separate test project that has Lib1 as a dependency; it won't build and I get linker errors. The unresolved externals are the functions I am trying to call within Lib1 that are from Lib2.

This is all fixed when I include Lib2 in my test project as well.

This all makes sense to me of course; I can test that Lib2 is not being built into Lib1..

My question is: is there a way to do this? I would ideally like to be able to deploy Lib1 as a standalone lib without requiring Lib2. (Lib2 is actually just a Lib from the Windows Platform SDK, so it's not really a big deal...)

Is this not allowed because it would allow people to "hide" third party libraries in their own, or something?

What would be a professional approach to this problem?

Thanks!

--R

Answer 1

I would not advise using a librarian to take Windows' library contents into your own library -- it's likely that that's against the license.

I see two possibilities

1. Documenting the dependency
2. Using a #pragma in your .h file that requests the .lib to be linked against. If VS can find it, it's the same as including it on your link line.

http://msdn.microsoft.com/en-us/library/7f0aews7(VS.80).aspx

 #pragma comment(lib, "libname.lib")

Answer 2

You need to use a tool called a librarian to do this. A librarian allows you to create and modify library (.lib) files. In visual studio check under the Librarian section of your project properties. A command line version also comes with visual studio (lib.exe).

Answer 3

Just document the dependencies of your lib.

As long as the library you depend on is available to anyone that could use your library, this is the preferred solution. Especially considering that the library user could also depend on this platform SDK lib - if you had it embedded then he'd get funny linker errors with multiply defined symbols.