Re: Missing links of libraries (*.so) on Debian 11

[songbird]

Greg Wooledge wrote:
...
> And yes, "ldd /path/to/the-program" would also be useful information.

  my guess is that the OP did not know that they needed to
install the build-depends for this package and then tried
to build it.

  hopefully i'm wrong, but if i'm not a simple answer is
to install the build-depends for the package.  they may
need to add a deb-src line to their /etc/apt/sources.list
before doing that install.


  songbird

Re: Missing links of libraries (*.so) on Debian 11

[The Wanderer]

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



signature.asc
Description: OpenPGP digital signature

Re: Missing links of libraries (*.so) on Debian 11

[Greg Wooledge]

On Mon, Jan 16, 2023 at 03:39:41PM +0100, Thomas Schmitt wrote:
> 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

> To be exacting:
> The bug would be in the build system, not in the source.

You're assuming that the program was dynamically linked against this
library.

I'm betting the program does a dlopen() and passes the wrong filename.

It would be quite useful if we could be told the ACTUAL DETAILS of the
problem.  The name of the program that's not working, and a terminal
paste of the errors that are obtained when trying to run it.

(Why do people HIDE this stuff??)

And yes, "ldd /path/to/the-program" would also be useful information.

Re: Missing links of libraries (*.so) on Debian 11

[Thomas Schmitt]

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.
(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


> and the various versions are not compatible to
> each other. The symlink with the supported version number (only
> one integer) must be used.

If the SONAME of a library changes, its Debian maintainer has to decide
whether this shall be reflected by creating a new package. Ideally the old
version will be supported for a while in parallel.
See readline5, readline6, and current readline (which has SONAME 8, i
wonder what happened to 7).


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 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.
But let's see what ldd reports.


Have a nice day :)

Thomas

Re: Missing links of libraries (*.so) on Debian 11

[Greg Wooledge]

On Mon, Jan 16, 2023 at 11:15:33AM +, piorunz wrote:
> On 16/01/2023 10:33, Avtansh Gupta wrote:
> > */usr/lib/x86_64-linux-gnu/libaudit.so*
> > 
> > This is the missing .so file in debian11. This file was present on the
> > previous versions of Debian and other Linux distros as well.
> 
> Incorrect. You just did not installed it yet :)
> 
> $ lsb_release -d
> Description:Debian GNU/Linux 11 (bullseye)
> 
> $ apt-file search libaudit.so
> libaudit-dev: /usr/lib/x86_64-linux-gnu/libaudit.so
> libaudit1: /lib/x86_64-linux-gnu/libaudit.so.1
> libaudit1: /lib/x86_64-linux-gnu/libaudit.so.1.0.0
> 
> Your file is there. Install first package and your program hopefully will
> start working again.

On Mon, Jan 16, 2023 at 01:20:18PM +0100, Vincent Lefevre wrote:
> On 2023-01-16 17:02:19 +0530, Anurag Aggarwal wrote:
> > The tool is looking for .so file to run, not for build.
> 
> This tool is buggy since the .so symlink may point to any version
> of the library, and the various versions are not compatible to
> each other. The symlink with the supported version number (only
> one integer) must be used.

Both of these responses are correct.  piorunz's response is technically
correct, and might even give a working result... or it might not.
There is indeed a libaudit.so file in the -dev package, but it's intended
to be used when building a program that uses the dynamically linked
libaudit, not for loading a library at runtime.

Vincent's response is correct, but doesn't really give a way forward.

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.

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.
It should either be dynamically linked against libaudit.so.1 (or whichever
version of libaudit was in use when it was built), or it should be
dynamically loading libaudit.so.1 (or libaudit.so.0 or whatever) instead
of libaudit.so.

Fixing this will require changing the source code of the broken program,
and then rebuilding it.  Rebuilding it will require libaudit-dev to be
installed.

If the broken program was written against a different API version of
libaudit (something older, perhaps) then the changes might be nontrivial.

Re: Missing links of libraries (*.so) on Debian 11

[Christoph Brinkhaus]

Am Mon, Jan 16, 2023 at 08:28:59PM +0800 schrieb Ruiyang Peng:
> On 2023/1/16 18:33, Avtansh Gupta wrote:
> > Hello All,

Hello,

> > I recently noticed that some of the library soft links on my Debian 11
> > system are missing which were there in the previous versions. I have a
> > program loading one of these shared objects dynamically but is
> > failing as it is unable to locate the file.
> > 
> > */usr/lib/x86_64-linux-gnu/libaudit.so*
> > 
> > This is the missing .so file in debian11. This file was present on the
> > previous versions of Debian and other Linux distros as well.
> > 
> > A similar pattern is observed with the other files(*.so) in the same
> > folder.
> > 
> > Could someone let me know what the change is and what is the new
> > convention being used?
> > -- 
> > *Regards,*
> > 
> > *Avtansh Gupta*
> > *+91 8743068185*
> What about trying pkg-config? Maybe it can tell you where it is.
 
Please excuse the late reply, I think I have missed the first post(s).

apt-cache search libaudit|grep ^libaudit
libaudit-common - Dynamische Bibliothek für Sicherheitsprüfungen - gemeinsame 
Dateien
libaudit1 - Dynamische Bibliothek für Sicherheitsprüfungen
libaudit-dev - Header files and static library for security auditing

I guess you have to install some or all of the packages.

Kind regards,
Christoph
-- 
Ist die Katze gesund
schmeckt sie dem Hund.

Re: Missing links of libraries (*.so) on Debian 11

[Ruiyang Peng]

On 2023/1/16 18:33, Avtansh Gupta wrote:

Hello All,

I recently noticed that some of the library soft links on my Debian 11 
system are missing which were there in the previous versions. I have a 
program loading one of these shared objects dynamically but is 
failing as it is unable to locate the file.


*/usr/lib/x86_64-linux-gnu/libaudit.so*

This is the missing .so file in debian11. This file was present on the 
previous versions of Debian and other Linux distros as well.


A similar pattern is observed with the other files(*.so) in the same 
folder.


Could someone let me know what the change is and what is the new 
convention being used?

--
*Regards,*

*Avtansh Gupta*
*+91 8743068185*

What about trying pkg-config? Maybe it can tell you where it is.

Re: Missing links of libraries (*.so) on Debian 11

[Vincent Lefevre]

On 2023-01-16 17:02:19 +0530, Anurag Aggarwal wrote:
> The tool is looking for .so file to run, not for build.

This tool is buggy since the .so symlink may point to any version
of the library, and the various versions are not compatible to
each other. The symlink with the supported version number (only
one integer) must be used.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Missing links of libraries (*.so) on Debian 11

[Anurag Aggarwal]

>
>
>
> The .so symbolic are not for running programs, they are for building
> them. For running, you only need the .so.vers links.
>
> If a program dynamically loads directly a .so, it is probably bugged.
>

The tool is looking for .so file to run, not for build.

We need to dynamically load .so as it may not be present on all linux
distributions. For e.g. Ubuntu 16.04

On Ubuntu 20.04 and other distributions we have libaudit.so which symlinks
to libaudit.so.1.0.0.0

On Debian 11, we see a symlink named as libaudit.so.1 which links to
libaudit.so.1.0.0.0

-- 
Anurag Aggarwal

Re: Missing links of libraries (*.so) on Debian 11

[piorunz]

On 16/01/2023 10:33, Avtansh Gupta wrote:

*/usr/lib/x86_64-linux-gnu/libaudit.so*

This is the missing .so file in debian11. This file was present on the 
previous versions of Debian and other Linux distros as well.


Incorrect. You just did not installed it yet :)

$ lsb_release -d
Description:Debian GNU/Linux 11 (bullseye)

$ apt-file search libaudit.so
libaudit-dev: /usr/lib/x86_64-linux-gnu/libaudit.so
libaudit1: /lib/x86_64-linux-gnu/libaudit.so.1
libaudit1: /lib/x86_64-linux-gnu/libaudit.so.1.0.0

Your file is there. Install first package and your program hopefully 
will start working again.


--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Re: Missing links of libraries (*.so) on Debian 11

[Nicolas George]

Avtansh Gupta (12023-01-16):
> I recently noticed that some of the library soft links on my Debian 11
> system are missing which were there in the previous versions. I have a
> program loading one of these shared objects dynamically but is failing as
> it is unable to locate the file.
> 
> */usr/lib/x86_64-linux-gnu/libaudit.so*
> 
> This is the missing .so file in debian11. This file was present on the
> previous versions of Debian and other Linux distros as well.
> 
> A similar pattern is observed with the other files(*.so) in the same folder.
> 
> Could someone let me know what the change is and what is the new convention
> being used?

The .so symbolic are not for running programs, they are for building
them. For running, you only need the .so.vers links.

If a program dynamically loads directly a .so, it is probably bugged.

Regards,

-- 
  Nicolas George