A experiência de resolver alguns problemas sobre bibliotecas dinâmicas em tempo de compilação-gcc, g ++, cmake general

Na verdade, cmake basicamente gera makefiles. Compilei a biblioteca muduo antes e encontrei um problema, consulte o problema do git

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

Ao descrever o problema naquele momento, a biblioteca boost foi baixada do site oficial da época

./b2

./b2 install

Mas ainda apareceu

/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

Na verdade, neste momento, podemos usar alguns métodos para resolver esse problema de maneira fácil e fácil. Geralmente, o arquivo da biblioteca de conexão falha ou a biblioteca não é encontrada. Acho que podemos fazer isso. Isso tornará mais fácil para nós solucionar o erro.

1. Um ponto chave para fazer bom uso de --verbose

Podemos ver o caminho de pesquisa do vinculador quando estamos no cc gcc g ++, podemos usar esses métodos

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

Você pode usar esses métodos para ajudá-lo facilmente a solucionar problemas durante a compilação. Ele pode imprimir o caminho de pesquisa do vinculador. Foi assim que descobri o motivo da falha de compilação, porque há duas com o mesmo nome .so biblioteca, a O problema anterior era porque encontrou outra biblioteca, mas este método é muito fácil de usar, ele pode imprimir o caminho de pesquisa da biblioteca.

Como o vinculador usado pelo gcc para vincular durante a compilação é / usr / bin / ld, como podemos confirmar da maneira mais simples se podemos encontrar a biblioteca para vinculação precisa durante a compilação?

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


ou

ld -lpthread

2. O uso de ldconfig pode resolver o problema de bibliotecas ausentes durante a compilação?

Acho uma pena que não posso. Por quê? Porque tentei muitas vezes, acho que é impossível, porque o resultado do gcc --verbose me diz que não posso.

Descreva meu fenômeno experimental:

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

Eu também adicionei meu caminho de pesquisa personalizado

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

sudo ldconfig, e descobri que a biblioteca realmente foi carregada (é claro, não colocamos a biblioteca no diretório de nível do sistema antes, mas em qualquer diretório especificado por nós), usei ldconfig -p e fez efeito

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:~$ 

Mas a busca de caminho é realmente insatisfatória ao 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:~$ 

Descobrimos que não encontramos nosso caminho durante a compilação. Claro, podemos definir o caminho da biblioteca durante gcc -L, e esse caminho será pesquisado primeiro

Depois de olharmos para a descrição do man ldconfig, há uma descrição importante

NAME
       ldconfig - configure dynamic linker run-time bindings

Ou seja, ldconfig é o link da biblioteca de tempo de execução dinâmico analisada, que é a biblioteca de tempo de execução. Endereço de referência:

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文件,但是要知道函数的原型。显式链接有时称为动态加载或运行时动态链接。

Mas se usarmos

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

Depois disso, o problema acima pode ser facilmente resolvido

Acho que você gosta

Origin blog.csdn.net/qq_32783703/article/details/106677854
Recomendado
Clasificación