On 2023-01-16 at 09:39, Thomas Schmitt wrote:
> Hi,
>
> Nicolas George wrote:
>
>> The .so symbolic are not for running programs, they are for
>> building them. For running, you only need the .so.vers links.
>
> Yes, but at build time, the actually used SONAME is recorded in the binary.
> ldd will show library.so.SONAME as run-time library.
>
>
>> If all the OP cares about is "make it work right now", then installing
>> the libaudit-dev package MIGHT be sufficient. If it doesn't work, then
>> see below.
>
> I doubt that. The -dev packages usually contain stuff which is needed
> for building binaries from source code. .h files and possibly an .a file
> for statical linking.
>
> What is needed is the runtime package with the library SONAME version
> which the binary expects. ldd is supposed to tell which this is.
This would be accurate if the library is being loaded by ld.so-style
dynamic loading, but...
> (As you stated, Debian offers libaudit1 of source package "audit" with
> libaudit.so.1 and libaudit.so.1.0.0. It does not look like there are
> others.)
>
>
>> Ideally, the OP should contact the maintainer(s) of the program in
>> question, and try to get the program fixed so that it works properly.
>
> Vincent Lefevre wrote:
>
>> This tool is buggy since the .so symlink may point to any version
>> of the library,
>
> Before accusing the developer, one should make sure that the binary
> is indeed linking to .so without SONAME.
> This can be checked by
>
> ldd /...path.../...to.../binary-tool
...while I could be wrong, my interpretation of posts thus far is that
the program involved may be using dlopen()-style dynamic loading - and
more specifically dlopen()ing not libaudit.so.1 (or any other SONAME),
but the raw name libaudit.so, with no SONAME specified.
If that's correct, then the binary is not expecting any library SONAME
version, but rather the raw .so filename. That's clearly a buggy/broken
design, unless there's something we're/I'm missing, but it's something
that a developer might have wound up doing.
> Nicolas George wrote:
>
>> Fixing this will require changing the source code of the broken
>> program, and then rebuilding it.
>
> To be exacting:
> The bug would be in the build system, not in the source.
If the source is, in fact, dlopen()ing the .so name rather than the
other, then the bug could indeed be in the program source. (Though
there's room to argue that a program's build system integration *is*
part of its source.)
>> If the broken program was written against a different API version of
>> libaudit (something older, perhaps) then the changes might be nontrivial.
>
> SONAME counting usually begins by 1. So i doubt that there is an older
> version.
Are you sure? On my system (recent but not current Debian testing):
for soname in `seq 0 12` ; do echo -n "${soname} " ; dlocate
"\.so\.${soname}$" | cut -d ':' -f 1 | sort -u | wc -l ; done
0 361
1 288
2 155
3 75
4 53
5 143
6 81
7 27
8 22
9 18
10 13
11 12
12 11
That should be a count of installed packages which ship at least one
library with the specified SONAME - and it sure looks to me as if a
significant fraction (in fact, a plurality) have a SONAME of 0.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature