> On March 21, 2014, 4:10 p.m., Hrvoje Senjan wrote: > > this seems to broke kded modules loading here: > > Cannot load library /usr/lib64/libkdeinit5_kio_file: > > (/usr/lib64/libkdeinit5_kio_file.so: cannot open shared object file: No > > such file or directory) > > Hrvoje Senjan wrote: > err, s/kded modules/kio plugins > > Alex Merry wrote: > Ah, I see. The old code *only* worked for kioslaves, and now it works > for everything *but* kioslaves. Although I'm not sure why I didn't run into > this in my testing. > > I think the correct solution here is to do the lookup in klauncher, > though. > > Alex Merry wrote: > Ah, I'm getting the error now. Possibly it was something to do with the > multiple patches I had lying around for kinit, kservice and kio. > > Alex Merry wrote: > https://git.reviewboard.kde.org/r/116935/ should fix it.
FTR: it fixes the issue, tnx. another side-effect left: Could not open kconf_update using a library: Cannot load library /usr/lib64/libkdeinit5_kconf_update: (/usr/lib64/libkdeinit5_kconf_update.so: cannot open shared object file: No such file or directory) - Hrvoje ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116927/#review53702 ----------------------------------------------------------- On March 20, 2014, 10:18 p.m., Alex Merry wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/116927/ > ----------------------------------------------------------- > > (Updated March 20, 2014, 10:18 p.m.) > > > Review request for KDE Frameworks and David Faure. > > > Repository: kinit > > > Description > ------- > > Fix kdeinit module lookup > > KLibrary's lookup magic is not so magic these days - is just uses > QCoreApplication::libraryPaths, which is not what we want. Instead, we > let dlopen() do the searching for us, plus hack in a check in the > library installation directory for kinit (since dlopen() called from Qt > does not respect kdeinit5's RUNPATH). > > This should cover most common cases (module installed to standard > location, module installed to same location as the kinit framework, > mdoule in LD_LIBRARY_PATH), and if it still fails we just fall back to > the normal executable. > > Rename kinit_library_path() to generate_socket_name() > > This reflects what the function actually does. Also got rid of the > (mostly) ifdef'd-out code that gave the function its original name. > > Add comment about fragility of lookup based on installation vars > > > Diffs > ----- > > src/kdeinit/CMakeLists.txt c4e3c49ea28d4e96be9ee1fa02f801052945d01e > src/kdeinit/kinit.cpp 82d570c4453cf083e525125edd448b97d8d11bd3 > > Diff: https://git.reviewboard.kde.org/r/116927/diff/ > > > Testing > ------- > > Built and installed. Ran kdeinit5, which reported that it was launching > "libkdeinit5_klauncher", rather than "/home/kf5-devel/kf5/bin/klauncher" as > it did previously. klauncher process then has "[kdeinit]" in its process > title in `ps xu`. > > > Thanks, > > Alex Merry > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel