Description of problem: After the upgrade of lxqt to 0.10 and the switch to %cmake_qt5 seems some breakage was introduced, as some of the libraries have been moved to different paths. As an example: [user@localhost ~]$ lxqt-config-appearance lxqt-config-appearance: error while loading shared libraries: liblxqt-config-cursor.so: cannot open shared object file: No such file or directory [user@localhost ~]$ rpm -qf $(which lxqt-config-appearance) lxqt-config-0.10.0-2.mga6 in 0.9 libraries were located directly in %_libdir: [user@localhost ~]$ locate liblxqt-config-cursor.so /usr/lib64/liblxqt-config-cursor.so Now they are in subdirectories: [user@localhost ~]$ urpmf lxqt-config-cursor.so lxqt-config:/usr/lib64/lxqt-config/liblxqt-config-cursor.so lxqt-config:/usr/lib/lxqt-config/liblxqt-config-cursor.so As a workaround LD_PRELOAD=/usr/lib64/lxqt-config/liblxqt-config-cursor.so lxqt-config-appearance works to run lxqt-config-appearance. List of installed lxqt packages: [user@localhost ~]$ rpm -qa | sort | grep lxqt lib64lxqt0-0.10.0-3.mga6 lib64lxqt-globalkeys0-0.10.0-3.mga6 lib64lxqt-globalkeys-ui0-0.10.0-3.mga6 lib64lxqt-mount0-0.9.0-1.mga5 lxqt-about-0.10.0-2.mga6 lxqt-common-0.10.0-2.mga6 lxqt-config-0.10.0-2.mga6 lxqt-globalkeys-0.10.0-3.mga6 lxqt-notificationd-0.10.0-3.mga6 lxqt-openssh-askpass-0.10.0-3.mga6 lxqt-panel-0.10.0-3.mga6 lxqt-policykit-0.10.0-3.mga6 lxqt-powermanagement-0.10.0-3.mga6 lxqt-qtplugin-0.10.0-2.mga6 lxqt-runner-0.10.0-3.mga6 lxqt-session-0.10.0-3.mga6 task-lxqt-0.10.0-1.mga6 task-lxqt-minimal-0.10.0-1.mga6 @Nicolas: As you updated lxqt to 0.10 without asking or notifying me as the maintainer, and seems without much testing, assigning this to you to fix this regression. Reproducible: Steps to Reproduce:
CC: (none) => doktor5000Assignee: neoclust => mageia
Fixed in svn
Status: NEW => RESOLVEDResolution: (none) => FIXED
Well seems more like a workaround to me and probably introduced by our %cmake_qt5. Not necessary on fedora, and this will likely not scale if we need to add an ld.so.conf for many library packages ...
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
Assignee: mageia => doktor5000
no this would be the same with %cmake this is beause we disable RPATH. Try to look before criticize ;)
CC: (none) => mageia
Please try new rpm with RPATH disable in spec file
Please reopen if any pb
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
Same problem persists: [user@localhost]â[09:26:54]â[~] rpm -qf $(which lxqt-config-appearance) lxqt-config-0.10.0-4.mga6 [user@localhost]â[09:27:16]â[~] lxqt-config-appearance lxqt-config-appearance: error while loading shared libraries: liblxqt-config-cursor.so: cannot open shared object file: No such file or directory [â]â[user@localhost]â[09:29:21]â[~] Seems to be caused by this commit: https://github.com/lxde/lxqt-config/commit/f7dd81930f389fc84b7caac94187c8487632a725 which is related to https://github.com/lxde/lxqt/issues/793 which also seems to affect Debian as well when RPATH is disabled. So https://github.com/lxde/lxqt-config/commit/0818173 is actually partly faulty because it uses INSTALL_RPATH instead of DESTINATION or similar, or did I misunderstand?
Ok, seems we're missing a patch from upstream that was added yesterday: http://svnweb.mageia.org/packages?view=revision&revision=908884 Now readelf -d /usr/bin/lxqt-config-appearance | grep -iE "RPATH|RUNPATH" also shows that the RUNPATH has actually been added as %_libdir/lxqt-config/ and lxqt-config-appearance starts as usual. Sidenote: as we pass -Wl,--enable-new-dtags to the linker, RPATH is actually converted into RUNPATH, which basically has the same effect (it's only considered after LD_LIBRARY_PATH but still before , but also defeats standard rpath checks like /usr/lib/rpm/check-rpaths - which does affect quite a lot of packages ...