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