Do static libraries, which depend on other slibs need the actual 'code' from them to work?

Sorry about the vague question title, I just want to ascertain some things.

Static libraries don't link with other static libraries, right?

So when I write a slib: A, that uses functionality of another: B, all I have to provide are the headers of B to A, and only those, even if A actually uses functionality from B? Yes?

As long as exe: X, which uses A,has B.lib specified as linker input?

So that at link time, the linker takes A.lib, which basically only knows that a function of B was called somewhere inside its code, and somehow fills that information from B.lib, making A.lib 'whole', before X gets linked with the now working parts of it?

The motivation behind these questions is to get rid of some linker warnings 4006 and discarded double definitions, and I think that should do the trick, if this is actually a valid way of doing it.

Yes, you have got it pretty much right. Executables (and DLLs) which depend on static libraries cannot be created without those dependencies being resolved, but static libraries that contain dependencies on other static libraries do not require those dependencies to be resolved at static library creation time. In fact, the process of creating a static library does not involve the linker at all.

Can't really add the Neils answer except to say that a static library is really just a whole bunch of object (.o) files collected into a single indexed file. So what works for a .o file will work for a static library.