Is the "library file" part of the final executable. If it is an object file in a statically linked library, it will only be part of the final executable if it resolves an otherwise unresolved external symbol. (This is the definition of a library.) If you never use any symbol in the object file, it won't be part of your executable, and it's as if the source file wasn't part of the application.
If the library is dynamically loaded, the situation is slightly
different; a .dll
is loaded as a unit (and not object file by
object file, so it's not really a library), but if there are no
unresolved symbols which would be resolved by loading the DLL,
it won't be loaded either.
What you probably want to do is link against the object files,
and not against a library. In Visual Studios, this means
putting all of the sources in the same project. Or... you can
link the library as a .dll
, and then explicitly load it using
LoadLibrary
. (This is what we do for libraries which are only
referenced because they have constructors of static objects
which register themselves.)