Support both dynamic and static linking for C++ about intercom

[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.