This website says there are 2 ways of using shared object files (.so):
- Dynamically linked at run time. The libraries must be available during compile/link phase. The shared objects are not included into
the executable component but are tied to the execution. - Dynamically loaded/unloaded and linked during execution (i.e. browser plug-in) using the dynamic linking loader system functions.
This makes sense since we can use -l flag in gcc to link the shared library during building and then we don’t need to use libdl functions (dlopen() and others) in our code (the library automatically loads the functions we use that are included from the header file of the shared library).
Other way is using libdl and loading the functions from shared library explicitly by providing function names as strings. This method seems to not require the libraries to be present at build time at all.
We could also use the first approach with some “stub” library during build time and then just change the file once we have the actual shared library. This however seems a little hacky. Is that a bad approach?
How are things done in the real world? Is the second approach used for plugin architecture (as website says) since we don’t necessarily have the shared library at bild time and first approach only if we have the library at build time?