Linking static libraries in visual studio with composite dependencies

Suppose you have two static libraries A and B such that A references methods from B. Is it possible to statically link an executable to A and B such that there are not unresolved symbols in B referenced by A?

Here is my situation:

When I try to link everything up that way in Visual Studio 2010, there are unresolved symbols b开发者_JAVA技巧etween A and B.. but not between the application and A. The symbols it complains about have the __imp prefix (which do not, and should not, exist in B's DUMPBIN). Why is it looking for symbols with the __imp prefix even though none of the libs are built as DLL's and I have included all of the required "Additional Library Dependencies/Directories" in all of the projects? Also, everything is built with the exact same compiler.

EDIT: It may be helpful to know that if library B is built as a DLL with an import library instead of a static library, everything will link up correctly.

EDIT: I am almost certain it is not a preprocessor condition causing a declspec() or something, because there are no linker errors when the App uses B.. just when A uses B.

ANSWER: Both Edwin and JimR are correct, there was actually a macro being used in a header causing a declspec, but I was too stubborn to notice it when they first mentioned that possibility. Thanks guys for your patience.

the dependecies should not matter ! they may even be circular ,like A refs B and B refs A. It sounds to me (since you get linker errors) that either you don't have headerfiles for those libs (do you declare funcs from A in B by hand or funcs from B in A) or the headerfiles compile differently in your program and in your libs (due to some #define or compiler option). Do you use the same calling conventions in both prog and libs ?

I do not have MSVS 2010 to look at, so take this with a grain of salt.

If the symbols have imp in the name, that means either there's a declspec(dllimport) floating around somewhere, a (possibly embedded in the code) compiler switch forcing A to see B as a DLL or you're linking old stuff and not what's currently being produced by the build process.

Was the project you're using imported from an older version of MSVS? I had a similar problem with a poorly managed project that was imported into MSVS 2008 a few years ago...

Either way, check A's build environment carefully and make sure you look for pragmas that embed compiler/linker switches.

Since your used lib B as a DLL before is it possible that when you build lib A your lib B was still a DLL and when you changed lib to library you forgot to rebuild A.