This is a good primer on the subject. One of the major projects I maintain at $work is an apache module, which has given me so much grief because of the fact t

This is a good primer on the subject. One of the major projects I maintain at $work is an apache module, which has given me so much grief because of the fact that it gets dynamically loaded (and then unloaded, and then reloaded) It's been very enlightening, but there's no shortage of frustration. One major points is that a dynamically loaded library can have undefined symbols that are found (or not!) at runtime. This can introduce a lot of trouble when trying to make a test binary. Especially in apache's case, since any of the `ap_` symbols are only compiled into the executable, and aren't available as a static or shared library. In that situation, the only recourse that I'm aware of is to supply your own implementations of those functions that get compiled into the test binary (not the dynamic library under test, since that will create a collision when it's loaded) Another thing to consider is that linux/elf shared libraries can be either dynamically loaded or dynamically linked. This is not true on all platforms, so it's not advisable to lean into it if portability matters. I recommend reading the ld.so manpage[0] -- in particular it outlines many environment variables to control the runtime linker. Notably, LD_DEBUG can be a life saver. Lastly, I'll also warn against using any global/static memory in a dynamically loaded library. It can be unloaded/reloaded, and that can create a lot of havoc, especially if a pointer to that memory gets saved somewhere that survives the unload, and then is accessible after the library gets reloaded. libprotobuf is a major victim of these types of issues - which is why (or a major contributor) to why the libprotobuf-lite library exists. [0] https://man7.org/linux/man-pages/man8/ld.so.8.html https://man7.org/linux/man-pages/man8/ld.so.8.html