ldconfig creating bad symlink
According to my research, the (mis-)behaviour of ldconfig
is triggered by the content of the file libbaccats-stub-9.0.6.so
, specifically its 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
Apparently that header tells ldconfig
to create a symlink with that name.
Proof: If I rename libbaccats-stub-9.0.6.so
to libbaccats-stub-9.0.6.so.BAD
then ldconfig
duly creates a symlink
libbaccats-7.4.4.so -> libbaccats-stub-7.4.4.so.BAD
and if I compress libbaccats-stub-9.0.6.so
with gzip
instead then ldconfig
complains
ldconfig: /usr/lib64/libbaccats-stub-9.0.6.so.gz is not an ELF file - it has the wrong magic bytes at the start.
and leaves my libbaccats-7.4.4.so
symlink alone.
So while I haven't found a way to make ldconfig
create the correct symlink, there's at least a way to prevent it from recreating the wrong one: delete, compress or otherwise mangle the file /usr/lib64/libbaccats-stub-9.0.6.so
.
Of course the real solution would be to set the SONAME
field in libbaccats-stub-9.0.6.so
correctly, but that would have to happen in the build process of the bacula-director
package.