Question

I am trying to find a good way to determine what module at link time is causing a certain library to get processed as a “/DEFAULTLIB” as seen in the verbose linker output from Visual Studio.

Here is my situation, I have several static library pre-requisites and each has a release and a debug version (BlahD.lib and Blah.lib). For some reason at link time all of the *D.lib’s are processed as default libraries even though I am building a release with the non-debug libs specified as “Additional Dependencies”. If I never build the debug versions of the static libraries those *D files wouldn’t exist and there would be a linker error (can’t open file).

I can get my project to build successfully by specifying /NODEFAULTLIB for all of these offending .lib files. All the release libraries link up and everyone is happy. But I want to understand what is going on here. What is causing these *D.lib files to be processed by the linker? Is my only hope to write some kind of script that dumpbins everything in this massive project and its dependant projects (microsoft support)? Even then I don’t understand what to look for in the dumpbin output, does this apply to the .lib files as well the .obj files?

Answer 1

Look for #pragma comment(lib) in the source. See if it perhaps is dependent on a #define – This is a common way for a SDK to ensure that the right libs are linked, and you may need to define THESDK_DEBUG or THESDK_RELEASE for the logic to work out.

Additional information:
I discovered in Visual Studio 2008 that even commenting out the statement from the *.idl file does not work, as in:

//cpp_quote("#pragma comment( lib, \"MYLIB.lib\")")

The compiler still adds MYLIB.lib as a DEFAULTLIB, and it winds up in the *.obj file. Make sure you remove the line completely from the code!