Como lidar com nomes conflitantes de duas bibliotecas compartilhadas?

Question

No meu sistema Linux Mint 17.3, instalei os pacotes libglfw2 e libglfw-dev . Como o GLFW v3 não está disponível nos repositórios, optei por compilá-lo manualmente usando as instruções aqui .

Quase todas as instruções que encontrei on-line indicam que para vincular ao GLFW v2, eu deveria usar -lglfw enquanto para o GLFW v3, deveria ser -lglfw3 . No entanto, fazer -lglfw3 deu o erro:

/usr/bin/ld: cannot find -lglfw3

enquanto usa -lglfw deu muitos erros como:

1.cpp:(.text+0x49): undefined reference to <function_name>

Só para ter certeza, todos os caminhos em C_INCLUDE_PATH e LD_LIBRARY_PATH estavam corretos. No entanto, depois de desinstalar o pacote do GLFW v2, instalei usando apt-get e executando ldconfig , -lglfw funcionou sem nenhum problema. Parece que, em algum lugar no arquivo CMake (eu acho), há um bug resultando em conflito de nomes.

A minha pergunta é: Se eu tiver duas fontes que forneçam as bibliotecas compartilhadas com o mesmo nome, e se eu precisar delas, o que posso fazer (sem mergulhar na configuração da compilação) para contornar o problema? Posso alterar manualmente os nomes dos arquivos so de forma confiável?

    

Answer 1

Bibliotecas compartilhadas são chamadas, por exemplo libfoo.so-x.y.z , com a idéia de que z é incrementado para pequenas alterações (totalmente compatíveis), y é incrementado para adições de API que mantêm compatibilidade com versões anteriores, enquanto alterações para x são reservadas para grandes mudanças de API compatível). O programa executável (verifique, por exemplo, a saída de ldd(1) para um executável) informa a biblioteca que o programa solicita, pelo número principal ( libfoo.so.x ) e qual biblioteca é usada para preencher essa dependência ( libfo.so.x.y.z ). Os "links contra libfoo.so.x " são fixados no tempo de compilação, o exato y.z na inicialização. Assim, você pode alterar y e / ou z e ter programas ainda funcionando e, por exemplo, libfoo.so.3 e libfoo.so.4 instalados ao mesmo tempo, com alguns programas usando um ou os outros sem conflitos.

Se você olhar os diretórios para bibliotecas, verá uma cadeia de links simbólicos como libfoo.so -> libfoo.so.x -> libfoo.so.x.y.z ; ao vincular com -lfoo , o vinculador seguirá isso e adicionará libfoo.so.x como dependência ao executável e usar libfoo.so.x.y.z para resolver os símbolos.

Este maquinário é feito sob medida para obter sempre o mais recente libfoo ao compilar, embora tenha versões antigas para aplicativos legados. Assim, muitas vezes você verá, por exemplo libbar.so e libbar3.so (e seu farm de links simbólicos) para poder construir contra a versão 2 ( -lbar , se a versão legada não numerada for 2) ou 3 ( -lbar3 ).

O maquinário de construção deve ser capaz de resolver isso, mas é bastante complicado (e nem todos estão empolgados com a idéia de que sua última e mais brilhante versão 3 permanecerá ao lado da versão 2).

Sua melhor aposta é confiar em sua distribuição para configurar essa confusão para você.