CODEWITHSUNDEEP
windowsvisual-c++dllstatic-libraries
ForeverLearning
ForeverLearning

Reputation: 6675

Static/Dynamic linking confusion

I seem to be misunderstanding something here. I have a DLL (say DLL_1) that has some C++ classes exported for consumption by clients.

A static library consumes these exported classes (say SLib_1).

There is one other DLL (say DLL_Client) that only depends on the aforementioned static library and therefore links against SLib_1. So I have:

DLL_Client ==> SLib_1 ==> DLL_1

While building SLib_1 does the linker resolve the exported classes from DLL_1? Does that part happen only when DLL_Client is being built?

Depending on the answer to the above, I have another question. Consider that I have yet another static library, say SLib_2. If I redraw the dependency path above like this:

DLL_Client ==> SLib_2 ==> SLib_1 ==> DLL_1 (each module only knows and links against the module that follows it)

Should the symbols exported by DLL_1 be visible to DLL_Client? I have no problems while compiling/linking this whole set up. My problem happens only at runtime. That is, when I use Dependency Walker to load DLL_Client, I find that it complains about not being able to resolve the exported functions in DLL_1.

What gives?

Upvotes: 1

Views: 166

Answers (1)

Jerry Coffin
Jerry Coffin

Reputation: 490008

For your first question, a static library is just a collection of object files. Nothing is resolved when you build the static library (in fact, if you just had the headers, so you could compile, you could build the static library without any of the other code even existing yet). The dependencies in the static library will only be resolved when you link those object files into your DLL.

For your second, the short answer is no. When/if a static library depends on another library (static or dynamic), the static library does nothing to make the symbols from the library(ies) it depends on visible to the final user. This comes back to the fact that it's just a collection of object files. Putting object files in a library doesn't normally1 change anything about visibility of symbols, or anything similar.

In short, if DLL_Client needs functions in SLib_2 and also directly uses functions from DLL_1, it needs to link against both SLib_2.lib and DLL_1.lib.

1 Lest somebody bring them up, I'll add that libraries do often contain a few symbols that have somewhat...special visibility, such as weak externals. Even here, it's not putting them in the library that makes them special though -- it's just that when you put something in a library is nearly the only time those special visibility options are really necessary or useful.

Upvotes: 1

Related Questions