What are the use cases of dlopen vs standard dynamic linking?

Question

According to the doc, dlopen is used in conjunction with dlsym to load a library, and get a pointer to a symbol.

But that's already what the dynamic loader/linker does. Moreover, both methods are based on ld.so.

There actually seems to be two differences when using dlopen:

1. The library can be conditionally loaded.
2. The compiler is not aware of the symbols (types, prototypes...) we're using, and thus does not check for potential errors. It's, by the way, a way to achieve introspection.

But, it does not seem to motivate the use of dlopen over standard loading, except for marginal examples:

1. Conditional loading is not really interesting, in terms of memory footprint optimization, when the shared library is already used by another program: Loading an already used library is not increasing the memory footprint.
2. Avoiding the compiler supervision is unsafe and a good way to write bugs... We're also missing the potential compiler optimizations.

So, are there other uses where dlopen is prefered over the standard dynamic linking/loading?

Answer 1

So, are there other uses where dlopen is prefered over the standard dynamic linking/loading?

Typical use-cases for using dlopen are

• plugins
• selecting optimal implementation for current CPU (Intel math libraries do this)
• select implementation of API by different vendors (GLEW and other OpenGL wrappers do this)
• delay loading of shared library if it's unlikely to be used (this would speed up startup because library constructors won't run + runtime linker would have slightly less work to do)

Avoiding the compiler supervision is unsafe and a good way to write bugs... We're also missing the potential compiler optimizations.

That's true but you can have best of both worlds by providing a small wrapper library around delay loaded shared library. On Windows this is done by standard tools (google for "DLL import libraries"), on Linux you can do it by hand or use Implib.so.

Answer 2

I did this in a Windows environment to build a language switch feature. When my app starts it checks the configuration setting which language.dll should be used. From now on all texts are loaded from that dynamically loaded library, which even can be replaced during runtime. I included also a function for formatting ordinals (1st, 2nd, 3rd), which is language specific. The language resources for my native language I included in the executable, so I cannot end up with no texts available at all.

The key is that the executable can decide during runtime which library should be loaded. In my case it was a language switch, or as the commentators said something like a directory scan for plugins.

The lack of monitoring the call signature is definitely a disadvantage. If you really want to do evil things like overriding the prototype type definitions you could do this with standard C type casts.