When we use the asynchronous event-driven model to ensure that the main program logic remains unchanged, each business is loaded in the form of a dynamic link library, which is the so-called plug-in. Linux and Windows provide system calls for loading and processing dynamic link libraries, which is very convenient. This article records a problem during use.
1、Linux
Linux provides a set of APIs to dynamically load libraries:
dlopen, open a dynamic library, and make some preparations for using the library.
dlsym, find the value of the symbol in the opened library.dlclose, close the library.
dlerror, returns a string describing the error message of the last call to dlopen, dlsym, or dlclose.
Include header file:
#include <dlfcn.h>
Function definition:
void * dlopen( const char * pathname, int mode);
Function description narration: mode is the open mode, and its value has multiple values. The functions implemented on different operating systems are: The difference is that under Linux, it can be divided into three categories according to function:
(1) Resolution method
RTLD_LAZY: Before dlopen returns, no analysis is performed for undefined symbols in the dynamic library (only valid for function references. For variable references It is resolved immediately).
RTLD_NOW: Needed before dlopen returns. It is parsed that all the symbols are not defined, and it is assumed that the analysis cannot be found. In dlopen, NULL will be returned, and the error is: undefined symbol: xxxx.......
(2) The scope can be used in combination with the parsing method through "|".
RTLD_GLOBAL: The symbols defined in the dynamic library can be resolved by other libraries opened later.
RTLD_LOCAL: Contrary to the role of RTLD_GLOBAL, the symbols defined in the dynamic library cannot be relocated by other libraries opened later.Assume that there is no indication of RTLD_GLOBAL or RTLD_LOCAL. The default is RTLD_LOCAL.
(3) Action mode
RTLD_NODELETE: The library is not unloaded during dlclose(), and the static variables in the library are not initialized when the library is loaded again using dlopen() in the future. This flag is not a POSIX-2001 standard.
RTLD_NOLOAD: Do not load the library.
On Linux, applications that use dynamic linking need to be linked with the library libdl.so, that is, using the option -ldl. However, it is not necessary to link with dynamically loaded libraries when compiling.
A problem encountered: When one of my modules is dynamically loading one of my dynamic library OpenMylib.so, then the dynamic library OpenMylib.so will execute the Init() initialization function in the library, and this Init is other dynamic libraries The function interface is called, and my OpenMylib.so will be dynamically loaded by other modules. Some global variables in OpenMylib.so will be used by other modules, and we are using (void *)dlopen("./OpenMylib. so", RTLD_NOW ); There was a crash, saying that it was an illegal memory access. I think this should be related to other dynamic library Init interfaces used in OpenMylib.so, causing other modules to not load OpenMylib.so, so we changed it to (void *)dlopen("./OpenMylib.so", RTLD_NOW|RTLD_GLOBAL ); It’s Ok
2. Windows dynamically loads DLL
There are three main Windows API functions, namely LoadLibrary, GetProcAddress and FreeLibrary.
(void *)::LoadLibrary(path);
FARPROC GetProcAddress( HMODULE hModule, LPCSTR lpProcName ); // // DLL module handle, // function name
FreeLibrary (DLL library handle);
If the DLL is not in the same directory of the caller, it can be loaded with LoadLibrary (L "DLL absolute path"). But if another DLL is called inside the called DLL, the call will still fail at this time. The solution is to use LoadLibraryEx:
LoadLibraryEx("DLL absolute path", NULL, LOAD_WITH_ALTERED_SEARCH_PATH);
By specifying LOAD_WITH_ALTERED_SEARCH_PATH, the system DLL search order starts from the DLL directory.