Dynamic loading of modules.
These functions provide a portable way to dynamically load object files (commonly known as 'plug-ins'). The current implementation supports all systems that provide an implementation of dlopen() (e.g. Linux/Sun), as well as HP-UX via its shl_load() mechanism, and Windows platforms via DLLs.
Opens a module.
If the module has already been opened, its reference count is incremented. If not, the module is searched in the following order:
- If file_name exists as a regular file, it is used as-is; else
- If file_name doesn't have the correct suffix and/or prefix for the platform, then possible suffixes and prefixes will be added to the basename till a file is found and whatever is found will be used; else
- If file_name doesn't have the ".la"-suffix, ".la" is appended. Either way, if a matching .la file exists (and is a libtool archive) the libtool archive is parsed to find the actual file name, and that is used.
At the end of all this, we would have a file path that we can access on disk, and it is opened as a module. If not, file_name is opened as a module verbatim in the hopes that the system implementation will somehow be able to access it.
Use operator bool() to see whether the operation succeeded. For instance,
if(module)
{
void* func = nullptr;
}
Dynamic loading of modules.
Definition module.h:45
bool get_symbol(const std::string &symbol_name, void *&symbol) const
Gets a symbol pointer from the module.
- Parameters
-
file_name | The name or path to the file containing the module, or an empty string to obtain a module representing the main program itself. |
flags | The flags used for opening the module. |
A portable way to build the filename of a module.
The platform-specific prefix and suffix are added to the filename, if needed, and the result is added to the directory, using the correct separator character.
The directory should specify the directory where the module can be found. It can be an empty string to indicate that the module is in a standard platform-specific directory, though this is not recommended since the wrong module may be found.
For example, calling build_path()
on a Linux system with a directory of /lib
and a module_name of "mylibrary" will return /lib/libmylibrary.so
. On a Windows system, using \Windows
as the directory it will return \Windows\mylibrary.dll
.
- Parameters
-
directory | The directory the module is in |
module_name | The name of the module |
- Returns
- The system-specific filename of the module
- Deprecated:
- 2.76: You will get the wrong results most of the time. Use the constructor instead with module_name as the basename of the file_name argument.