Support both dynamic and static linking for C++

[Rantanen]

Static linking would be nice in general, but the real reason I want it is supporting kcov on circleci.

Currently circleci has trouble measuring coverage results from our C++ integration tests. I suspect this is due to kcov not catching the dynamically loaded library: https://github.com/SimonKagstrom/kcov/issues/230

An "easy" workaround for us would be to run the unit tests with static linkage for coverage. That would also allow testing dynamic linking on normal tests and static linking during coverage runs. (Of course the dynamic loader wouldn't get coverage results, but at least everything else would).

[Fluxie]

For the automatic discovery #67 to the libraries need to be explicitly linked into to the executable. Otherwise we cannot discover the COM classes with dl_iterate_phdr. => They are no longer loaded dynamically at runtime with dlopen.

Is this still an issue?

[Rantanen]

What does that mean?

Libraries need to be explicitly linked into the executable

Isn't this the case, ESPECIALLY with static linking?

They are no longer loaded dynamically at runtime with dlopen

How is this a problem with static linkage?

Or did I misunderstand you wondering whether we could just drop this issue as implementing it would make the automatic discovery of COM classes harder in some way? This issue is still an issue as far as I know.

My current mental draft for static linking is...

• The COM servers need to be explicitly compiled for static linking. This renames the DllGetClassObject (and other global functions) with some sort of library prefix, such as TestLib_DllGetClassObject
• The C++ bits are initialized by registering the library manually:

  int main() {
    intercom::register_library(
         TestLib_DllGetClassObject,
         ... // libid? libname? whatever else we need
    );
  }

• After this the intercom::CreateInstance, etc. can be used like before.
  • We'd still use the generated headers, etc. that define the IIDs. The only thing that changes is how the correct DllGetClassObject, etc. entry points are found.
• Static linking is not supported with Windows builtin COM functionality.

This would not be the "recommended" way; But some use cases might require static linking: embedded platforms, single-file deployments, etc. so we should make it possible even if not convenient.