On Thu, Nov 23, 2023 at 02:33:55PM +0800, d tbsky wrote:
> Hi:
>I saw systemd 252 release notes:
>
> Private shared libraries (libsystemd-shared-nnn.so,
> libsystemd-core-nnn.so) are now installed into arch-specific
> directories to allow multi-arch installs.
>
> I don't know if that is related, but in RHEL 9.2/9.3, "ldd" result like
> below:
>
> > ldd /usr/lib64/systemd/libsystemd-core-252.so
> linux-vdso.so.1 (0x7ffed6708000)
> libsystemd-shared-252.so => not found
> ...
I don't think this is related. The "arch-specific directories" here
means that e.g. /usr/lib64/systemd/ is used instead of
/usr/lib/systemd/. Neither path is in the normal library search path.
Those libraries are not found by ldd because they are not in the
public library search path. The binaries that use those libraries
use RPATH to add /usr/lib64/systemd/ to the library search path
and thus find libsystemd-core-252.so and libsystemd-shared-255.so.
$ ldd /usr/lib/systemd/systemd | rg libsystemd
libsystemd-core-255.so => /usr/lib64/systemd/libsystemd-core-255.so
(0x7fd54100)
libsystemd-shared-255.so => /usr/lib64/systemd/libsystemd-shared-255.so
(0x7fd540a0)
> it seems other distributions(debian,suse) are in the same situation.
> it will cause utilities like ReaR(relax and recover) failed to find
> the libraries. I don't know the reason behind the design. should the
> situation fixed by systemd, by os distribution, or the utility need to
> handle that itself?
I don't know what ReaR is, so I can't comment on that specifically.
But in general, there is no "problem". Those libraries have an unstable
ABI, so they are tucked away in a separate directory and are not
intended to be found during a search. This seems to work just fine.
Zbyszek
