Open Rantanen opened 6 years ago
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?
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...
DllGetClassObject
(and other global functions) with some sort of library prefix, such as TestLib_DllGetClassObject
int main() {
intercom::register_library(
TestLib_DllGetClassObject,
... // libid? libname? whatever else we need
);
}
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.
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).