Some point before commit #bfa28f1 in the frameworks branch a change was introduced that leads to a loader failure when starting Okular on OS X. This turns out to be caused by the fact that libokularplugin.dylib is linked with okularpart.dylib, and okularpart.dylib has an incorrect identity stored in it: ``` > otool -L /opt/local/share/qt5/qml/org/kde/okular/libokularplugin.dylib /opt/local/share/qt5/qml/org/kde/okular/libokularplugin.dylib: /opt/local/lib/libokularplugin.dylib (compatibility version 0.0.0, current version 0.0.0) /opt/local/libexec/qt5/Library/Frameworks/QtQuick.framework/Versions/5/QtQuick (compatibility version 5.6.0, current version 5.6.1) /opt/local/libexec/qt5/Library/Frameworks/QtQml.framework/Versions/5/QtQml (compatibility version 5.6.0, current version 5.6.1) /opt/local/lib/okularpart.dylib (compatibility version 0.0.0, current version 0.0.0) /opt/local/lib/libOkular5Core.7.dylib (compatibility version 7.0.0, current version 7.0.0) [SNIP] ``` Note the expected install path for okularpart.dylib, which is not correct but stems from: ``` > otool -L ldd /opt/local/share/qt5/plugins/okularpart.dylib /opt/local/share/qt5/plugins/okularpart.dylib: /opt/local/lib/okularpart.dylib (compatibility version 0.0.0, current version 0.0.0) /opt/local/lib/libOkular5Core.7.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) /opt/local/lib/libphonon4qt5.4.dylib (compatibility version 4.0.0, current version 4.9.0) [SNIP] ``` When I build Okular with the same configuration and install target settings on Linux there is no such error. In fact, libokularplugin.so does *not* reference okularpart.so, meaning that the linker editor determined that nothing from that library is used except for its public link libraries. A basic workaround is to create a symlinked /opt/local/lib/okularpart.dylib that points to the binary in Qt5's plugin directory. The most correct fix would be to correct the identity stored in that file on OS X, but this is somewhat debatable given that the library isn't required (and I'm not sure how to do this in cmake). Another fix which takes that particular fact into account is to adjust the target_link_libraries for the okular plugin, in mobile/components/CMakeLists.txt : ``` target_link_libraries(okularplugin Qt5::Quick Qt5::Qml Qt5::Core Qt5::Xml Qt5::Svg okularcore KF5::Bookmarks KF5::I18n KF5::IconThemes ) ``` This works on both Linux and OS X. On Linux, the resulting output from `ldd libokularplugin.so` is unchanged, which confirms the idea that okularpart.so is only used to link the KF5 Bookmarks, I18n and IconThemes frameworks indirectly. Reproducible: Always Steps to Reproduce: 1. checkout and build the frameworks branch at #bfa28f1 2. install 3. run Actual Results: A dynloader error that okularpart.dylib cannot be found Expected Results: no errors
Created attachment 100965 [details] patch for mobile/components/CMakeLists.txt
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!