https://bugs.kde.org/show_bug.cgi?id=452817
Fabian Vogt <fab...@ritter-vogt.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fab...@ritter-vogt.de,
| |kdelibs-b...@kde.org
Version|git-master |unspecified
Assignee|plasma-b...@kde.org |mp...@kde.org
Component|general |general
Product|kscreenlocker |frameworks-kcoreaddons
--- Comment #9 from Fabian Vogt <fab...@ritter-vogt.de> ---
(In reply to Luca Beltrame from comment #8)
> This happens because KLibexec looks up kscreenlocker_greet in /libexec, not
> /usr/libexec.
>
> From strace I ran on a nested Wayland session:
>
> [pid 13948] execve("/libexec/kscreenlocker_greet"
>
> But in openSUSE Tumbleweed it is installed in /usr/libexec.
>
> I had a discussion about it with Fabian on IRC about a possible cause:
>
> [12:35] <fvogt> The relative path is formed by going from /usr/lib64/ to
> /usr/libexec
> [12:36] <fvogt> During runtime the shared library is opened from /lib64/
> though, so it tries /libexec
> [12:36] <fvogt> i.e. incompatible with usrmerge
> [12:37] <fvogt> At least that's my theory
Looks like my theory is correct.
libkscreenlocker is built with /usr/lib64 as full libdir path and /usr/libexec
as full libexec path, so it tries to reach the greeter by doing
$self/../libexec/kscreenlocker_greet. In a usr-merged system, /lib64 is a
symlink to /usr/lib64 (or the other way around), so
/lib64/libKScreenLocker.so.5.24.80 and /usr/lib64/libKScreenLocker.so.5.24.80
refer to the same file. As /lib64 is earlier in the library search path than
/usr/lib64, the library is loaded as /lib64/libKScreenLocker.so.5.24.80 and the
path ends up as /lib64/../libexec/.
It works after forcing /usr/lib64/ earlier in the search path than /lib64.
Moving this over to kcoreaddons as the issue is with KLibexec.
--
You are receiving this mail because:
You are watching all bug changes.
