# Static libraries and loadable modules

**URL:** <https://discourse.cmake.org/t/static-libraries-and-loadable-modules/1176>\
**Category:** Code\
**Created:** [May 9, 2020, 12:48am UTC](https://discourse.cmake.org/t/static-libraries-and-loadable-modules/1176 "2020-05-09T00:48:01Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![alex](https://discourse.cmake.org/user_avatar/discourse.cmake.org/alex/32/125_2.png) [@alex](https://discourse.cmake.org/u/alex)\
**Post date:** [May 9, 2020, 12:48am UTC](https://discourse.cmake.org/t/static-libraries-and-loadable-modules/1176/1 "2020-05-09T00:48:01Z")

</div>

I am working on a library with a plugin system that currently works by having a plugin register itself on load. An app links with this library, as does the plugin. When `BUILD_SHARED_LIBS=ON`, the plugin loads correctly, but when set to `OFF`, it doesn’t crash or fail to load, it just doesn’t get registered.

I believe this is because when the library is static, the app and the plugin each get their own copy of everything, including the map of plugins.

On Linux, one can get around this using weak linkage, but there doesn’t appear to be much support for that in CMake (or on Windows, since it isn’t a standard language feature).

Here is a repository containing a minimal example: [https://github.com/alexreinking/cpp-plugin-example](https://github.com/alexreinking/cpp-plugin-example)

Is there a portable way of allowing an application which uses a static library to load a plugin that uses that library?

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [May 11, 2020, 4:39pm UTC](https://discourse.cmake.org/t/static-libraries-and-loadable-modules/1176/2 "2020-05-11T16:39:10Z")

</div>

The way Python ends up doing this is to just tell the linker to ignore the missing symbols when making the plugin. ELF platforms have various ways of spelling this (`-Wl,--no-as-needed -Wl,--unresolved-symbols=ignore-in-shared-libs` being the Linux way). macOS has `-undefined dynamic_lookup`. Better would be to mark the symbols as `weak` in the header and then doing a sanity check that some sentinel symbol is defined when the plugin loads (before it ends up calling other maybe-`nullptr` symbols).