La experiencia de resolver algunos problemas sobre bibliotecas dinámicas en tiempo de compilación-gcc, g ++, cmake general

De hecho, cmake esencialmente genera archivos MAKE. He compilado la biblioteca muduo antes y encontré un problema, vea el problema de git

https://github.com/chenshuo/muduo/issues/470

Al describir el problema en ese momento, la biblioteca boost se descargó del sitio web oficial en ese momento

./b2

./b2 install

Pero aun así apareció

/tmp/ccLjGYKC.o：在函数‘__static_initialization_and_destruction_0(int, int)’中：
main.cc:(.text+0x30)：对‘boost::unit_test::unit_test_log_t::instance()’未定义的引用
collect2: error: ld returned 1 exit status

De hecho, en este momento, podemos usar algunos métodos para resolver este problema fácil y fácilmente. Generalmente, el archivo de la biblioteca de conexión falla o no se encuentra la biblioteca. Creo que podemos hacer esto. Esto nos facilitará la tarea de solucionar el error.

1. Un punto clave para hacer un buen uso de --verbose

Podemos ver la ruta de búsqueda del enlazador cuando estamos en cc gcc g ++, podemos usar estos métodos

gcc -print-search-dirs
gcc Wl,--verbose
ld -lpthread --verbose

Puede usar estos métodos para ayudarlo fácilmente a solucionar problemas durante la compilación. Puede imprimir la ruta de búsqueda del enlazador. Así es como encontré el motivo del error de compilación porque hay dos con el mismo nombre. El problema anterior era porque encontró otra biblioteca, pero este método es realmente fácil de usar, puede imprimir la ruta de búsqueda de la biblioteca.

Debido a que el enlazador utilizado por gcc para enlazar durante la compilación es / usr / bin / ld, ¿cómo podemos confirmar de la manera más sencilla si podemos encontrar la biblioteca para un enlace preciso durante la compilación?

hanglei@zhanglei-virtual-machine:~$ gcc -lpthread
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o: in function `_start':
(.text+0x24): undefined reference to `main'
collect2: error: ld returned 1 exit status

ld -lpthread

2. ¿El uso de ldconfig puede resolver el problema de la falta de bibliotecas durante la compilación?

Creo que es una pena que no pueda. ¿Por qué? Porque lo intenté muchas veces, creo que es imposible, porque el resultado de gcc --verbose me dice que no puedo.

Describe mi fenómeno experimental:

vim /etc/ld.so.conf.d/xxx.conf

También agregué mi ruta de búsqueda personalizada

/home/zhanglei/ourc/xxx/bin.lnx/x64

sudo ldconfig, y descubrí que la biblioteca de hecho se ha cargado (por supuesto, no pusimos la biblioteca en el directorio de nivel del sistema antes, sino en cualquier directorio especificado por nosotros mismos), usé ldconfig -p y entró en vigencia

zhanglei@zhanglei-virtual-machine:~$ sudo ldconfig -p|grep iter
	libsciter-gtk.so (libc6,x86-64) => /home/zhanglei/ourc/xxx/bin.lnx/x64/libxxxx.so

zhanglei@zhanglei-virtual-machine:~$

Pero la búsqueda de ruta es realmente insatisfactoria al compilar

==================================================
/usr/bin/ld：模式 elf_x86_64
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o 成功
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crti.o 成功
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crti.o
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/crtbeginS.o 成功
/usr/lib/gcc/x86_64-linux-gnu/9/crtbeginS.o
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/libpthread.so 失败
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/libpthread.a 失败
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libpthread.so 成功
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libpthread.so
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.so 失败
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a 成功
/usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so 成功
打开脚本文件 /usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so
/usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so
打开脚本文件 /usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so
试图打开 libgcc_s.so.1 失败
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so.1 失败
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libgcc_s.so.1 成功
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libgcc_s.so.1
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.so 失败
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a 成功
/usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/libc.so 失败
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/libc.a 失败
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libc.so 成功
打开脚本文件 /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libc.so
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libc.so
打开脚本文件 /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libc.so
试图打开 /lib/x86_64-linux-gnu/libc.so.6 成功
/lib/x86_64-linux-gnu/libc.so.6
试图打开 /usr/lib/x86_64-linux-gnu/libc_nonshared.a 成功
/usr/lib/x86_64-linux-gnu/libc_nonshared.a
(/usr/lib/x86_64-linux-gnu/libc_nonshared.a)elf-init.oS
试图打开 /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 成功
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
/usr/lib/x86_64-linux-gnu/libc_nonshared.a
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.so 失败
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a 成功
/usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so 成功
打开脚本文件 /usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so
/usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so
打开脚本文件 /usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so
试图打开 libgcc_s.so.1 失败
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so.1 失败
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libgcc_s.so.1 成功
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libgcc_s.so.1
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.so 失败
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a 成功
/usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/crtendS.o 成功
/usr/lib/gcc/x86_64-linux-gnu/9/crtendS.o
试图打开 /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crtn.o 成功
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crtn.o
ld-linux-x86-64.so.2 needed by /lib/x86_64-linux-gnu/libc.so.6
found ld-linux-x86-64.so.2 at /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o: in function `_start':
(.text+0x24): undefined reference to `main'
/usr/bin/ld: 找到链结错误，删除可运行文件 a.out
collect2: error: ld returned 1 exit status
zhanglei@zhanglei-virtual-machine:~$

Descubrimos que no encontramos nuestra ruta en absoluto durante la compilación. Por supuesto, podemos definir la ruta de la biblioteca durante gcc -L, y esta ruta se buscará primero

Después de ver la descripción de man ldconfig, hay una descripción importante

NAME
       ldconfig - configure dynamic linker run-time bindings

Es decir, ldconfig es el enlace de la biblioteca dinámica en tiempo de ejecución analizada, que es la biblioteca en tiempo de ejecución. Dirección de referencia:

https://www.cnblogs.com/qinfengxiaoyue/archive/2012/05/27/2519703.html

linux:
dlopen

windows:
windows下调用动态库的方法：

1 隐式加载：即在程序中包含lib文件和.h文件，隐式链接有时称为静态加载或加载时动态链接。例如：

#include "somedll.h"

#pragma comment( lib, "somedll.lib")

   然后就可以直接调用此dll中的函数，注意运行时仍然需要somedll.dll。

 

2 显示加载：使用loadlibrary，GetProcAddress,FreeLibrary,不需要.h文件和.lib文件，但是要知道函数的原型。显式链接有时称为动态加载或运行时动态链接。

Pero si usamos

ln -s xxxx /usr/lib/libxxx.so

Después de esto, el problema anterior se puede resolver fácilmente.