title: Mysterious "unresolved symbols" linker errors when compiling against large static lib
body: <p>I am receiving a lot of strange LNK2001 and LNK2019 errors when attempting to compile and link against a somewhat large static library (developed in-house). Here are the facts:</p>
  
  <ul>
  <li>There are several static libs (most built in-house) all compiled into one large wrapper static lib for public consumption ("Pimpl" idiom). Essentially, we have libs <code>A</code>, <code>B</code>, and <code>C</code> all compiled into an internal/private lib called <code>D</code>. Then, we have an external/public lib that wraps around <code>D</code> called <code>E</code>.</li>
  <li>The final product is not an executable, but a plug-in for Adobe Illustrator. Plug-ins are essentially just a DLL with a couple special resources and a special entry point (<code>PluginMain()</code> function). Compiling and linking works just great until I use the <code>/INCLUDE</code> option to specify that <code>PluginMain</code> should always be exported.</li>
  <li>Creating a plug-in and linking against lib <code>D</code> works fine (no errors whatsoever). Creating a plug-in and linking against lib <code>E</code> gives over 100 unresolved symbol errors (symbols that should be present in <code>E</code>).</li>
  <li>When I run <code>DUMPBIN</code> on the <code>E.lib</code> file, it <em>appears</em> to have all the symbols that the linker is complaining about when trying to create a plug-in. However, I'm not entirely certain I understand all the output syntax from <code>DUMPBIN</code>...</li>
  <li>The libs are all cross-platform and compile and link just fine with GCC/LLVM on Mac.</li>
  </ul>
  
  <p>Most of the functions that the linker complains about are either plain functions or static member functions. Most of those look suspiciously like functions that the compiler might try to inline. I have tried disabling optimization and/or automatic inlining, but the same link errors are still present.</p>
  
  <p>Can anyone point me in the direction of some compile and/or link settings that might resolve the issue? Settings that are commonly misconfigured in situations like this? </p>
  
  <p>Perhaps there is a setting I missed that is causing the linker not to export these symbols when linking <code>E</code>? Perhaps there is a setting that forces the linker to export <strong>ALL</strong> symbols when linking <code>E</code> that I can try? Maybe a utility exists to help me inspect the lib symbols myself for a clue?</p>
  
  <p>I feel like I've tried everything, but it never hurts to ask. Thanks all.</p>
  
  <p><strong>EDIT 1:</strong> snowdude requested an actual link error:</p>
  
  <p><code>E.lib(PathArt.cpp.obj) : error LNK2001: unresolved external symbol "private: __thiscall E::PathSegPoint::PathSegPoint(struct D::PathSegPoint const &amp;)" (??0PathSegPoint@E@@AAE@ABU0D@@@Z)</code></p>
  
  <p>I should add that <code>E::PathSegPoint::PathSegPoint(const D::PathSegPoint&amp;)</code> is a private constructor for constructing an external/public consumable <code>E::PathSegPoint</code> object from an internal/private <code>D::PathSegPoint</code> object. Again, this is the "Pimpl" idiom. Some classes/functions are friends of <code>E::PathSegPoint</code> to enable this sort of construction.</p>