new install of Plasma5, testing on a new user account

get this error within systemsettings when trying to access the global shorcuts kcm module though other shortcut modules work fine

Failed to contact the KDE global shortcuts daemon
Message: Could not get owner of name 'org.kde.kglobalaccel': no such name
Error: org.freedesktop.DBus.Error.NameHasNoOwner

tried:
- reinstalled all packages possessing file names containing kglobalaccel and kdeinit
- ran kbuildsyscoca --noincremental

The dbus activator should try to run kglobalaccel5, see https://git.reviewboard.kde.org/r/116956/
-> Do you have a kglobalaccel5 binary, or was it re-renamed (by distro or whatever)?

have the binary /opt/kf5/bin/kglobalaccel5

if I try and run it

#/opt/kf5/bin/kglobalaccel5
/opt/kf5/bin/kglobalaccel5: error while loading shared libraries: libkdeinit5_kglobalaccel5.so: cannot open shared object file: No such file or directory

the .so exists

#ls -l /opt/kf5/lib64/libkdeinit5_kglobalaccel5.so
-rwxr-xr-x 1 root root 134624 Nov 28 13:03 /opt/kf5/lib64/libkdeinit5_kglobalaccel5.so

my PATH

#echo $PATH
/opt/kf5/bin:/usr/lib64/qt5/bin:/opt/kf5:.......................

thanks,

ps - probably should post on openSUSE forum as a special repo for KDE5 has been created to run parallel to KDE4

Code: Select all

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/kf5/lib64/

as workaround, but that should of course not be necessary.
The binary was linked against some other path and RPATH/RUNPATH not set correctly. File a bug at SuSE.

yup, needed to run /opt/kf5/bin/kglobalaccel5 also (as I didn't want to log back in)

thansk,

Notice that these packages (which are installed in parallel) are not maintained by the openSUSE community KDE team.

einar wrote:Notice that these packages (which are installed in parallel) are not maintained by the openSUSE community KDE team.

I know, thus I posted the issue in a thread on the openSUSE forum that's pretty much dedicated to that particular repo and monitored by it's creator

Just for clarification:
My Plasma5 packages do set LD_LIBRARY_PATH accordingly during login.
And I cannot reproduce the issue here, the global shortcuts KCM and kglobalaccel5 work fine.
I suppose the most likely reason here was a mixture of packages, i.e. plasma5-session from the normal KDE:Frameworks5 or the main 13.2 repo installed which does not set the LD_LIBRARY_PATH (the "official" openSUSE packages install to /usr/ anyway).

luebking wrote:The binary was linked against some other path and RPATH/RUNPATH not set correctly.

Correct. I had to pass -DCMAKE_SKIP_INSTALL_RPATH=ON to cmake, otherwise the build fails with the following error:

Code: Select all

[ 1202s] CMake Error at libkworkspace/cmake_install.cmake:60 (file):
[ 1202s]   file RPATH_CHANGE could not write new RPATH:
[ 1202s]
[ 1202s]     /opt/kf5/lib64
[ 1202s]
[ 1202s]   to the file:
[ 1202s]
[ 1202s]     /home/abuild/rpmbuild/BUILDROOT/plasma5-workspace-5.1.1-88.1.x86_64/opt/kf5/lib64/libkworkspace5.so.5.1.1
[ 1202s]
[ 1202s]   No valid ELF RPATH or RUNPATH entry exists in the file;
[ 1202s] Call Stack (most recent call first):
[ 1202s]   cmake_install.cmake:16618 (include)


Any idea about this?

Sounds like the library was build w/o -rpath
That's not uncommon, but would be required for anything that is supposed to link anything that's not in /lib or /usr/lib (unless you handle that w/ the LD_LIBRARY_PATH, of course

http://www.cmake.org/Wiki/CMake_RPATH_h ... full_RPATH

luebking wrote:Sounds like the library was build w/o -rpath
That's not uncommon, but would be required for anything that is supposed to link anything that's not in /lib or /usr/lib (unless you handle that w/ the LD_LIBRARY_PATH, of course

Well, I do handle it with LD_LIBRARY_PATH as mentioned, but that means that you have to set it manually when wanting to run KF5 applications outside the Plasma 5 session at the moment. Not having to do that would probably be nicer...

http://www.cmake.org/Wiki/CMake_RPATH_handling#Always_full_RPATH

Thanks for the pointer, I will have a look at that.