Add a common mistake case for header-only classes in components build doc

docs/component_build.md

Index: docs/component_build.md
diff --git a/docs/component_build.md b/docs/component_build.md
index 06341c21cd36e494134db3783d76e5ee184eb612..1de4e4d53e077d1065d6996300a7cc0c12c4155b 100644
--- a/docs/component_build.md
+++ b/docs/component_build.md
@@ -253,3 +253,16 @@ the object file might not be brought into the link. Even if it is brought in
 today, it might not be brought in due to completely unrelated changes in the
 future. The result will be undefined symbol errors from other components. Use
 source sets if your component is made up of more than one target.
+
+### Exporting a symbol that is not linked in your component

[brettw, 2017/02/09 21:58:44]

I think the confusion you ran into is specific to header implementations. I
think (hope?) other instances of not defining the implementation in your module
will be pretty obvious.

So I'd make this more direct:

### Exporting functions and classes implemented in headers

When you implement a symbol in a header the compiler will put that in every
necessary translation unit and the linker will pick one. If the symbol is never
referenced by code in the shared library it's supposed exported from, it will
never be instantiated and never exported. The result will be undefined external
symbol errors when linking. Exported symbols should be declared in a header but
always implemented in a .cc file.

+
+If an exported symbols is not linked as part of its own component then it is
+not exported by the generated shared library. Other components that expect to
+see this symbol are not be able to find it which results in an undefined symbol
+error:
+
+    some_file.obj : error LNK2001: unresolved external symbol <some definition>
+
+For example this can happen if you have a header-only class that is not used
+inside the module itself. A simple fix in this case is to define the symbol in
+its own .cpp file.