matlab_wrapper | Easy to use MATLAB wrapper for Python

You might be able to make a single shared library for all purposes: the PyInit_foo that Python looks for will simply be ignored by Matlab, after all. But you still might not want to alter your main library to support such uses: maybe it has other compiled clients that need no wrapper, or maybe it’s supposed to be installed separately from special wrappers, or maybe it needs to be usable on a machine without the hosts installed.

Another option is to make one shared library for each ultimate client. Linking the same object files into each defeats some of the purpose of shared libraries, like sharing memory between a Matlab process and a concurrent Python process each using your library. It might (I’m not sure) also end up running global constructors more than once, but those are best avoided anyway. These issues might not matter for your use cases, but the same build issues as before for the real C++ library apply.

Otherwise, you’ll have multiple shared libraries in one process (one for the “real” C++ library and another for the host language module). There are ABI issues here; one way to avoid them is by providing, as you suggested, a C API in the core library. There are, of course, other ways of dealing with those issues, especially when you control all the compilations.

There are yet more approaches: the main library could include the interface for one host language (especially if it can also serve as the C API) but not another, or one shared library could serve multiple languages without including the C++ core. Given the C API, you may be able to use a FFI from the host language (ctypes for Python) instead of writing (more) C specifically for the host.

Whatever link strategy you choose, compiling is always the same: just #include whatever of your headers are relevant (those for the C API if appropriate) and any needed for the host language (if any) and go.