views:

111

answers:

2

We recently upgraded to Visual Studio 2008 from 2005, and I think those error started after that.

In our solution, we have a multitude of projects. Many of those are utility projects, or projects containing core functionality used by other projects. The output of those is lib files that are linked to when building the projects generating the final binaries using the "Project dependencies..." option.

One of the other projects---Let us call it ResultLib---generates a DLL, and it needs one single function from the core project. This function uses only static function from its own source file, but the project in its entirety uses a lot of low-level Windows functions and also imports a DLL---Let us call it Driver.dll.

Our problem is that when building ExtLib, the linker complains about a multitude of unresolved externals, for example all functions exported from Driver.dll, since its lib file is not specified when linking. If we try to fix this by adding all lib files used by other projects that use all of the core project, our resulting ResultLib DLL ends up importing Driver.dll and also exporting all functions defined in it.

How do we tell Visual Studio to only try to resolve symbols that are actually used?

A: 

Your libs object fi8lesare probably not granular enough. If you access a function in a library, any other functions from the same object file are included and by definition any functions they call will need to be resolved. Lets take an example:

I have three functions in my library, f1, f2 and f3. Function f1 and f2 are in the same souce file (and therfore will end up in the same object file). Function f3 is in a seperate file.

If my application calls f3 the linker will only include the code for f3. If my app calls f1 or f2 the linker will always include code for bothe functions.

This is why some library projects end up with many small source files.

Tim Ring
Thanks for your response, but the function that I am calling is in fact one of the few functions in this C file, and none of the other functions call any other functions in the library.
Moses Palmér
A: 

Well, it appears that I mistakenly thought that the linker was smart enough to remove unused symbols before the final linking.

What I had to do was to manually exclude all unnecessary files from build. For all projects listed as dependencies of the DLL project. Argh.

Moses Palmér