I have a really strange issue with kauth. Since a few days ago, it doesn't work anymore (it gives the error "KAuth was compiled with a working backend, but was unable to load it! Check your installation!"). It worked a couple of weeks ago, and if I reinstall the (previously compiled) old version it still works. But if I recompile the same version, it doesn't.
Something must have changed on the system that produces a broken kauth when compiling. It's not the toolchain, since I tested with the same version that was used to compile the working kauth version. Any ideas of what could be causing this or how to debug it?

check the passed CMake vars. in KF5 world code is *really* sensitive on some vars being absolute. IOW, one can't use absolute LIB_INSTALL_DIR, and at least some Frameworks rely on PLUGIN_PATH being relative. at least here on openSUSE, KAuth still works (with both 5.2.0 and master)

Thank you! It looks like the problem is the -DKDE_INSTALL_USE_QT_SYS_PATHS=ON flag. Removing it and manually specifying -DQT_PLUGIN_INSTALL_DIR=lib/qt/plugins fixes it. I guess this should be fixed in kauth?

yes, but first e-c-m should expose something like e.g. CMAKE_INSTALL_FULL_QT_PLUGIN_INSTALL_DIR. alternatively, it shouldn't rely at all on installed location.
i fear there are many more cases across Frameworks and Workspace...

I'm impressed. I spent hours hunting this bug down and should have just checked the forum.

When it's built with DKDE_INSTALL_USE_QT_SYS_PATHS the PLUGIN_DIR is absolute, whereas otherwise it's relative.

so we end up with kauth looking in /usr/usr/share/...

https://git.reviewboard.kde.org/r/120603/

And to follow up, the review request was accepted, so this should be fixed in the next KAuth release.

šumski wrote:i fear there are many more cases across Frameworks and Workspace...

And you were right, kactivities is also affected by this https://bugs.kde.org/show_bug.cgi?id=340900