Biblioteca faltante do C ++ ao executar (comportamento SONAME)
Eu fiz um programa que usa duas bibliotecas compartilhadas (que eu compilei) e são colocadas assim:
<code>/home_directory_where_I_compile_and_run_everything -->/lib/libjson_linux-gcc-4.4.6_libmt.so -->/lib/libre2.so.0 </code>
Quando eu compilo meu programa eu passo a localização relativa dessas bibliotecas para o linker, assim:
<code>g++ ...... stuff ........ my_program.cc lib/libjson_linux-gcc-4.4.6_libmt.so lib/libre2.so.0 </code>
E compila bem, no entanto, quando executando o programa, ele não consegue encontrar libre2.so, e se eu inspecionar com o ldd, aqui está o que acontece:
<code>.... lib/libjson_linux-gcc-4.4.6_libmt.so (0x00007f62906bc000) libre2.so.0 => not found .... </code>
Aparentemente, ele reconhece que o caminho na libjson é relativo, mas não faz isso no libre2.so.0 (ele corta todo o caminho e apenas deixa o libre2.so.0)
Alguém pode me dizer por que isso acontece?
Além disso, existe uma maneira de modificar isso através de um argumento g + +?
Melhor.
* UPDATE * Whoa verificar isso! Eu mudei o nome de libre2.so.0 para stuff.so e tentei compilar essencialmente o mesmo assim:
<code>g++ ...... stuff ........ my_program.cc lib/libjson_linux-gcc-4.4.6_libmt.so lib/stuff.so </code>
E falha de qualquer maneira; não só falha, falha porque não consegue encontrar "libre2.so.0".
Por quê?
* UPDATE # 2 *
Saída parareadelf -d the_program.o
<code>0x0000000000000001 (NEEDED) Shared library: [lib/libjson_linux-gcc-4.4.6_libmt.so] 0x0000000000000001 (NEEDED) Shared library: [libre2.so.0] </code>
Agora, se eu pudesse fazer com que [libre2.so.0] fosse [lib / libre2.so.0] em vez disso, tudo ficaria bem.
* UPDATE # 3 *
Como @troubadour descobriu:
Quando um executável é vinculado a um objeto compartilhado que possui um campo DT_SONAME, quando o executável é executado, o vinculador dinâmico tentará carregar o objeto compartilhado especificado pelo campo DT_SONAME em vez de usar o nome do arquivo fornecido ao vinculador.
É por isso que funciona com libjson ..... e não com libre2.so.0. (libjson ..... então não tem uma entrada para SONAME).
E finalmente encontrei a pergunta exata para o que estou procurando:
Existe alguma maneira de informar ao vinculador gcc para ignorar as entradas SONAME em um arquivo de biblioteca compartilhada e vinculá-lo ao caminho de arquivo específico?