The use of dynamic libraries under Linux

Introduction

The dynamic library under the Linux environment is generally named Libxxx.so, with the LDD command parsing an executable program, you can see which dynamic libraries The program depends on, and the path. such as LDD./test

Linux-vdso.so.1 = (0x00007fffaab52000)

libc.so.6 =/lib64/libc.so.6 (0x0000003c4c800000)

/lib64/ld-linux-x86-64.so.2 (0x0000003c4c000000)

If a dependent library is not found, the program will not function correctly.

"Create a dynamic Library"

Util.cpp

1234	extern"C" int InsertSubStr(char* pszBuf, int nPos, char* pValue){     return1;}

When the code is CPP, the function can be overloaded, and the function name generated in the symbol will be decorated, such as _zwqinsertsubstrbstl. Add the extern "C" in the symbol is the original name, of course, you can not have the same function. If the function body uses the adornment, the header file definition must also be added, otherwise the caller will not find the function name when compiling.

Makefile

12345

libmyutil.so : util.o  g++ -shared -o libmyutil.so util.outil.o : util.cpp  g++ -fPIC -c util.cpp -o util.o

If there is no compilation error, the Libmyutil.so file is generated. Because the-shared compile option is used, if other library libabc.so are referenced in the code, they will not be reported at compile time (unlike Windows, which will unresolve external, or I have not found the Setup method). If the caller does not reference the library libabc.so, it will be loaded or run with an error. So know which libraries are referenced, preferably added in makefile, such as g++-shared-labc-o libmyutil.so UTIL.O

When QT creates a dynamic library, it generates several symbolic links with version numbers such as libxx.so.1.0.0, which can be added with CONFIG + = plugin so that no version number is available.

"Using dynamic Libraries"

Like windows, there are two ways of directly compiling links and loading them dynamically

1. Direct compilation of links

Include the function definition of the header file, call the function in the program, and then add-lmyutil to the makefile. Using the LDD command to parse the execution program, you can see the reference to libmyutil.so QT compilation, you need to specify the path LIB + = L in the Pro file. /lib-lmymodule

2. Dynamic loading

123456789101112131415161718192021

#include <dlfcn.h>typedefint(*fnTestFoo)(char* pszBuf, intnPos, char* pValue);  void*hso = dlopen("./libmyutil.so", RTLD_NOW);//RTLD_LAZY);//  if(!hso)  {    printf("dlopen failed:%s\n", dlerror());    return;  }  fnTestFoo fnTest = (fnTestFoo)dlsym(hso, "InsertSubStr");  char*perr = dlerror();  if(perr)  {    printf("load symbol failed:%s\n", perr);    return;  }  charszText[256]="abcdef";  fnTestFoo(szText, 2, "xyz");  printf("%s\n", szText);  dlclose(hso);

You can see the corresponding to the Windows function: Dlopen=loadlibrary,dlsym=getprocaddress. These functions are in libdl.so and are compiled with-LDL in makefile Dlopen

You can have the option Rtld_now/rtld_lazy, which is the load-time resolution dependency, the failure of the error to stop running, the latter is not resolved before running to the corresponding code, if there is a dependency error and then an incorrect.

Dynamically loading C + + classes

If you want to use a C + + class in a dynamic library, it is not possible to use it directly, because the constructor is not found at compile time. In fact, just output a function in the dynamic library, create the class object

CTest *getclass_dl (void)

{

Return (new CTest ());

}

That's it, the destructor is the same.

"Dependencies and Paths"

Under Windows you can use depends to see the dependencies of a library, and there are several tools under Linux that can achieve similar effects, such as the ldd of file dependencies mentioned above. If you want to see the function dependencies, you can use the NM command, such as NM test

12345678

0000000000601170 d _DYNAMIC                 w _Jv_RegisterClasses00000000004008e4 T _Z8callFunciPPcPFiS_zE                 U [email protected]@GLIBC_2.2.5                 U [email protected]@GLIBC_2.2.5                 U [email protected]@GLIBC_2.2.5                 U [email protected]@GLIBC_2.2.50000000000400da2 T main

where T (text) is in front of the address in this program; U (unresolved) represents the referenced external library function, and the corresponding library name. There is also W (weak), a (absolute) does not understand. There are also objdump commands that show the contents of the program in more detail.

When loading Dlopen dynamically, it is best to specify the full path, otherwise the current path may change. When compiling a linked library file, sometimes running the program will not find the library file error: Error while loading shared Libraries:libxxx.so.1:cannot open Shared object file:no such file or directory. Many times the path is not specified.

Unlike Windows, the DLL is placed in the EXE together, the load will be first looked up from the current path. The path of the library file under Linux is configured in/etc/ld.so.conf with the following line

Include ld.so.conf.d/*.conf

In the CONF.D directory, you can see the path to the library file required by other software, such as mysql-x86_64.conf with only one line:/usr/lib64/mysql

So if your own library file is not placed in the system library path such as/usr/lib64, you can also add myapp.conf file as this method, write/mylib, put it here.

sudo ldconfig update configuration (note slower), use Ldconfig-p|grep libmyxxx to see if your library is in the system's path. When the so file is added to the path, the configuration is not automatically updated.

If you do not want to change the system's library file path, you can also modify the environment variable Ld_library_path at run time, such as export ld_library_path= $LD _library_path:/my_library_path $./my_app

Original: https://www.cnblogs.com/chaos77/p/6874378.html

The use of dynamic libraries under Linux