Review Request 116927: Fix kdeinit module lookup

[Alex Merry]

> 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.
> 
> Hrvoje Senjan wrote:
>     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)

Huh.  I don't think that ever worked with KF5.  See https://git.reviewboard.kde.org/r/117024/


- Alex


-----------------------------------------------------------
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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140324/319a2d7e/attachment.html>