De acordo com minha pesquisa, o (des) comportamento de ldconfig
é acionado pelo conteúdo do arquivo libbaccats-stub-9.0.6.so
, especificamente seu SONAME
field:
ts@xenon:~> objdump -p /usr/lib64/libbaccats-stub-9.0.6.so
/usr/lib64/libbaccats-stub-9.0.6.so: file format elf64-x86-64
[...]
Dynamic Section:
NEEDED libc.so.6
SONAME libbaccats-9.0.6.so
Aparentemente, esse cabeçalho diz ldconfig
para criar um link simbólico com esse nome.
Prova: se eu renomear libbaccats-stub-9.0.6.so
para libbaccats-stub-9.0.6.so.BAD
, então ldconfig
criará um link simbólico
libbaccats-7.4.4.so -> libbaccats-stub-7.4.4.so.BAD
e se eu comprimir libbaccats-stub-9.0.6.so
com gzip
, então ldconfig
reclama
ldconfig: /usr/lib64/libbaccats-stub-9.0.6.so.gz is not an ELF file - it has the wrong magic bytes at the start.
e deixa meu symlink libbaccats-7.4.4.so
sozinho.
Portanto, embora eu não tenha encontrado uma maneira de fazer o ldconfig
criar o symlink correto, há pelo menos uma maneira de impedir que ele crie o erro errado: delete, comprima ou manipule o arquivo /usr/lib64/libbaccats-stub-9.0.6.so
.
É claro que a solução real seria definir o campo SONAME
em libbaccats-stub-9.0.6.so
corretamente, mas isso teria que acontecer no processo de compilação do pacote bacula-director
.