Solaris: Qual é a diferença entre os arquivos .so e .so.1?

Question

Estou tentando entender como / por que certos arquivos de biblioteca são carregados dinamicamente pelo vinculador no Solaris. Eu estou usando o ldd para ver isso (com o switch -s para ver quais caminhos são tentados pelo vinculador). Por exemplo, se eu executar "ldd / usr / local / bin / isql -s", noto que uma das bibliotecas pesquisadas é chamada "libodbc.so.1". Eu noto que isso NÃO corresponde a um arquivo que ele encontra ao longo do caminho chamado "libodbc.so". Então, finalmente, resolve para um lugar onde há um link simbólico entre "libodbc.so.1.0.0" e "libodbc.so.1". Minha pergunta é - qual é o significado do ".1" aqui? É para indicar um número de versão? Por que alguns instaladores criam esses links simbólicos, enquanto outros não?

    

Answer 1

Esta questão não é específica para o Solaris.

Quando você instala uma biblioteca compartilhada (ou um software que fornece uma biblioteca compartilhada), você obtém três arquivos, todos com aparência semelhante, mas com finalidades diferentes.

• libfoo.so.1.0.0 - Este é o arquivo de dados (regular). Ele contém a biblioteca em si. Você poderia ter vários destes, com diferentes versões. Dentro deste arquivo, há um campo ELF chamado SONAME , que é definido como libfoo.so.1 . No Linux, execute objdump -p libfoo.so.1.0.0 | grep SONAME para descobrir.
• libfoo.so → libfoo.so.1.0.0 - Este é um link simbólico que é usado ao compilar o software contra a libfoo. Quando você especifica -lfoo para o vinculador, ele procurará exatamente libfoo.so . Normalmente, libfoo.so nunca é um arquivo regular, é sempre um link simbólico que aponta para a versão do libfoo que você deseja usar para vincular. Em um ambiente de criação complexo, você pode ter várias versões da biblioteca e usar esse link simbólico para escolher, em relação à versão que deseja vincular.
• libfoo.so.1 → libfoo.so.1.0.0 - Este também é um symlink, que é usado quando você executa binários que precisam de sua biblioteca. Lembre-se do campo SONAME que mencionei? Quando você vincula um binário ao libfoo, o binário registrará o SONAME da biblioteca e o utilizará em tempo de execução.

Esta configuração permite que você tenha várias versões da mesma biblioteca instaladas lado a lado. Binários diferentes podem requerer versões diferentes da biblioteca, e cada binário encontrará a versão correta da biblioteca. Geralmente, o SONAME da biblioteca é alterado pelo upstream quando há uma alteração de API incompatível com versões anteriores. Todos os binários antigos ainda usam a API antiga, enquanto binários recém-vinculados usam a nova.

Alguns projetos de empacotamento, o Debian seria um exemplo, use pacote diferente nomes para diferentes versões de uma biblioteca. Isso permite que você instale e desinstale cada versão da biblioteca compartilhada de forma independente.

Existem alguns casos de borda. Por exemplo, dependências entre bibliotecas compartilhadas podem levar a duas versões sendo puxadas ao mesmo tempo. Considere:

foo → libbar.so.1, libbaz.so.1
libbar.so.1 → libbaz.so.1

Imagine que instalemos uma nova versão do libbaz e recompile o foo. Agora temos:

foo → libbar.so.1, libbaz.so.2
libbar.so.1 → libbaz.so.1

No tempo de execução, foo carregará libbaz.so.2 e libbar.so.1 , e libbar.so.1 carregará libbaz.so.1 . Veja o problema? Duas versões do libbaz são carregadas ao mesmo tempo. Não tenho certeza qual é a consequência exata em termos do layout do código na memória, mas na prática isso resulta em falhas.

    

Answer 2

Sim, o ".1" indica o número da versão. Isso possibilita ter várias versões da mesma biblioteca lado a lado, enquanto a versão mais comum possui um link sem número de versão.

Se não houver necessidade de distinguir entre versões diferentes, o sufixo da versão pode não estar presente.