More Shared Libraries-Dynamic Loading and Unloading
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Sometimes you might want to load some code at runtime without explicitly linking in that code. For example, consider an application that supports "plug-in" modules, such as a Web browser. The browser allows third-party developers to create plug-ins to provide additional functionality. The third-party developers create shared libraries and place them at a known location, such as a special directory. The Web browser then automatically loads the code in these libraries.
This functionality is available under Linux by using the dlopen function. You could open a shared library named libtest.so by calling dlopen like this:
dlopen ("libtest.so", RTLD_LAZY)
(The second parameter is a flag that indicates how to bind symbols in the shared library. We'll discuss the meaning of the second parameter later, but RTLD_LAZY is usually the setting that you want.) To use dynamic loading functions, include the <dlfcn.h> header file and link with the -ldl option to pick up the libdl library.
The return value from this function is a void * that is used as a handle for the shared library. You can pass this value to the dlsym function to obtain the address of a function that has been loaded with the shared library. For example, if libtest.so defines a function named my_function, you could call it like this:
void* handle = dlopen ("libtest.so", RTLD_LAZY);
void (*test)() = dlsym (handle, "my_function");
(*test) ();
dlclose (handle);
The dlsym system call can also be used to obtain a pointer to a static variable in the shared library.
Both dlopen and dlsym return NULL if they do not succeed. In that event, you can call dlerror (with no parameters) to obtain a human-readable error message describing the problem.
The dlclose function unloads the shared library. Technically, dlopen actually loads the library only if it is not already loaded. If the library has already been loaded, dlopen simply increments the library reference count. Similarly, dlclose decrements the reference count and then unloads the library only if the reference count has reached zero.
If you're writing the code in your shared library in C++, you will probably want to declare those functions and variables that you plan to access elsewhere with the extern "C" linkage specifier. For instance, if the C++ function my_function is in a shared library and you want to access it with dlsym, you should declare it like this:
extern "C" void foo ();
This prevents the C++ compiler from mangling the function name, which would change the function's name from foo to a different, funny-looking name that encodes extra information about the function. A C compiler will not mangle names; it will use whichever name you give to your function or variable.
Resolving Symbols in a Shared Library
When you link an executable against a shared library (by specifying the shared library when you link the executable, not using the dlopen mechanism described above), the linker allows you to generate an executable with references to functions and variables that aren't themselves in an executable. When you run the executable, Linux's dynamic loader locates and loads the appropriate shared libraries, and links in the missing symbols.
A shared library may also contain references to functions and variables that aren't themselves defined in the shared library. What happens when the shared library is used? That's what the second argument to dlopen specifies.
If you specify RTLD_LAZY, Linux doesn't worry about undefined symbols when you open the library or resolve a symbol using dlsym. However, when you attempt to use a function from the shared library that references an undefined symbol, Linux is forced to try to resolve the symbol. If it can do so, your program continues executing. If Linux can't resolve the symbol, it prints a message and ends your program.
If, instead, you specify RTLD_NOW, Linux resolves all undefined symbols immediately when you call dlopen. If it fails to resolve any of them, dlopen returns a null pointer.
But where does Linux look to resolve the undefined symbols in the shared library you loaded with dlopen? The symbols can be resolved from several places:
If your main executable exports any dynamic symbols (as if it were a shared library), these symbols may be used. Note, however, that by default ordinary executables do not export their functions and variables as dynamic symbols. To generate an executable that exports all of its functions and variables dynamically, specify the compiler flag -Wl,-export-dynamic when you link your executable.
If your main executable is linked against other shared libraries, the library you open with dlopen may use symbols from these.
Your main executable may load other shared libraries at runtime, using dlopen. By default, they cannot see each other's dynamic symbols. You can make these libraries' symbols visible to each other by specifying the bitwise or of the value RTLD_GLOBAL in the second argument to dlopen.
For example, suppose your main function dynamically loads and calls a function foo from libfoo.so. Here is what your main program's source file, main.c, might look like:
#include <assert.h>
#include <dlfcn.h>
int main ()
{
void* handle = dlopen ("libfoo.so", RTLD_LAZY);
void (*foo) () = dlsym (handle, "foo");
(*foo) ();
dlclose (handle);
return 0;
}
Now suppose foo calls another function bar, which is not included in libfoo.so. How could you make bar available to libfoo.so?
One choice would be to include bar in your main executable. You must, then, specify -Wl,-export-dynamic when you build it. For example:
% cc main.c bar.c -Wl,-export-dynamic -o main -ldl
A second choice would be to put bar in a separate shared library, and link it into your main executable. For example:
% cc bar.c -fPIC -shared -o libbar.so % cc main.c -o main libbar.so -ldl
A third choice would be to put bar in a separate shared library, and load it dynamically in main. Be sure to use the RTLD_GLOBAL flag; otherwise, libfoo.so will not see symbols exported by libbar.so. For example, this call would do the trick:
void* bar_handle = dlopen ("libbar.so", RTLD_LAZY|RTLD_GLOBAL);
Which option you choose depends on your needs. Linux provides you with a great deal of flexibility in controlling how shared libraries are loaded and used in your programs.