Windows C + + porting Linux (2) loading dynamic shared libraries with different __ static functions

Windows C + + porting Linux (2)-Different loading of dynamic shared libraries Brief introduction of system dynamic Shared library

The obvious disadvantage of a static library is that when the system runs many applications at the same time, and the application uses functions from the same function library, then each application will have multiple copies of the function. For frequently called functions, a large amount of memory and disk space will be consumed. In the Linux system, each programmer uses the static library at least 1M, if the machine runs 100 such programs, then occupies 100M above the memory, the disk application assumption has 2000, must close to waste 2G space, under the Linux system/usr/ There are thousands of executable files in the bin. This waste is a serious problem in the early stages of the computer.
The presence of a dynamic shared library solves this problem, and when the program uses a dynamic library, the connection is as follows: The program itself does not include the code of the function, but rather the shared code that is accessible at run time. When a compiled program is loaded into memory for execution, the function reference resolves and produces a call to the shared library, and the shared library is loaded into memory when necessary. In this way, only one copy of the shared library is saved for use by many programs and only one copy of the disk.
In Windows systems, dynamic shared libraries are files that have a. dll suffix. In Linux systems, dynamic shared libraries are files of. So suffixes. When Windows is programmed, the. dll file is placed under the project folder, and then the DLL file is added through the interface under the IDE. In the Linux system, modify the ld.so.conf file, or use the rpath command directly. In a program, another way of writing is to use a dynamic method of invoking a dynamic library. Here, the main introduction of Linux system dynamic loading process. the difference between platform functions

Windows	Linux
LoadLibrary	Dlopen
GetProcAddress	Dlsys
FreeLibrary	Dlclose

The following functions are reproduced from this blog, and this blog is written in great detail and is highly recommended if you want to learn more about loading dynamic library content. Dlopen

1) Dlopen
Function prototype: void *dlopen (const char *libname,int flag);
Feature Description: Dlopen must be called before Dlerror,dlsym and Dlclose, indicating that the library is to be loaded into memory and ready for use. If the library you want to load depends on other libraries, you must first mount the dependent library. Returns a null value if the Dlopen operation fails, and Dlopen returns the same handle if the library has already been loaded.
The libname in the parameter is generally the full path of the library, so that Dlopen will load the file directly, and if only the library name is specified, the following mechanism will be followed in Dlopen search:
-A. Ld_library_path lookup based on environment variables
-B. Find by/etc/ld.so.cache
-C. Find in/lib and/usr/lib directories, in turn.
The flag parameter represents how an undefined function is handled and can be used with Rtld_lazy or Rtld_now. Rtld_lazy means to temporarily not deal with undefined functions, first load the library into memory, and so on, and then use the undefined function; Rtld_now says to check for undefined functions immediately, and if so, Dlopen fails. Dlerror

Function prototype: char *dlerror (void);
Function Description: Dlerror can get the error message for the most recent dlopen,dlsym or dlclose operation, and NULL to indicate no error. Dlerror also clears the error message when it returns an error message. Dlsym

Function prototype: void *dlsym (void *handle,const char *symbol);
Function Description: After Dlopen, the library is loaded into memory. Dlsym can get the position (pointer) of the specified function (symbol) in memory. If the specified function is not found, DLSYM returns a null value. But the best way to determine whether a function exists is to use the Dlerror function. Dlclose

Function prototype: void *dlsym (void *handle,const char *symbol);
Function Description: After Dlopen, the library is loaded into memory. Dlsym can get the position (pointer) of the specified function (symbol) in memory. If the specified function is not found, DLSYM returns a null value. But the best way to determine whether a function exists is to use the Dlerror function. Example

On the Ubuntu14.04 we test a simple example.

  1//Gcc-o DL DL.C-LDL                                                                                                           
  2 #include <dlfcn.h>
  3 #include <stdio.h>
  4 int main (int argc, char **arg V)
  5 {
  6     void *handle;
  7     Double (*mycos) (double);//function pointer
  8     char *error;
  9     handle = Dlopen ("libm.so", rtld_lazy);
 (     !handle)         fprintf (stderr, "%s", Dlerror ());
 return         1;     mycos = Dlsym (handle, "cos");
 The     if (Error = Dlerror ())!= NULL)     {         fprintf (stderr, "%s", error);
 return         1;     printf ("%f:\n", Mycos (1.0));     Dlclose (handle);     0; 
 25}

This example is a simple process of loading a dynamic shared library. But I did compile with an error as follows:

Dl.cpp:15:29:error:invalid conversion from ' void* ' to ' double (*) (double) ' [-fpermissive]
Mycos = dlsym (Handle, "Co S ");

Later found that I wrote a CPP file, C language will be implicitly converted to the void* into other types of pointers, but C + + needs explicit conversion. I am used to writing C + + code, the suffix is CPP, and then use g++ compile when this error occurs.

Blogging is a good habit, sharing the lessons of the project and making progress together. The deficiencies, please give a lot of advice. Finally, thank you to the blogger who provided me with guidance on the project.