> On Aug. 25, 2015, 2:22 p.m., René J.V. Bertin wrote: > > > When built as SHARED as in the current code, libdraganddropplugin.dylib > > > gets installed to $PREFIX/share/qt5/qml/org/kde/draganddrop, but is given > > > an OS X install_name of $PREFIX/lib/libdraganddropplugin.dylib. This > > > mismatch can cause problems. > > > It is also given a compatibility_version of 0.0.0. > > > > Both properties are used only when the `dylib` is used as a shared library, > > because AFAIK they're only used by the dynamic loader when the reference > > information is available (i.e. stored in the binary by the link editor). > > Using `dlopen` on a random file, dylib or other, does not provide such > > information and thus it shouldn't matter what the loaded file claims for > > its install_name and/or compatibility_version. > > > > By contrast, there *is* a difference between shared libraries and loadable > > modules ("plugins" or `bundles` in OS X speak) on OS X. The latter cannot > > be used as shared libraries by the link editor (something that certain KDE4 > > projects sin against) while the former can be used as plugins without any > > issue. However, only plugins can have automatic access to the loader's > > symbols but that requires the loader to be specified at link time so not of > > much interest for generic plugins, kparts etc. > > NB: the `bundle` in this context is unfortunate because they are not > > generally bundles in the "app bundle" way. > > NB2: those KDE projects that use modules as shared libraries (kparts, in > > unit tests IIRC) led me to propose a patch to MacPorts's port:cmake which > > made cmake create modules with the same linker options as shared libraries > > (i.e. `-dynamiclib` instead of `-bundle`). I've since tried to get that > > patch removed, but it is still out there. > > Marco Martin wrote: > if this breaks on linux, it should be reverted for now
Reverted for now. I also reopened the bug report. Also for the qml side of things: https://mail.kde.org/pipermail/kde-frameworks-devel/2015-August/026281.html - Harald ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124892/#review84338 ----------------------------------------------------------- On Aug. 23, 2015, 9:16 p.m., Hanspeter Niederstrasser wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124892/ > ----------------------------------------------------------- > > (Updated Aug. 23, 2015, 9:16 p.m.) > > > Review request for Build System, KDE Software on Mac OS X, KDE Frameworks, > Plasma, and Harald Sitter. > > > Bugs: 342962 > https://bugs.kde.org/show_bug.cgi?id=342962 > > > Repository: kdeclarative > > > Description > ------- > > The kdeclarative plugins (draganddropplugin, kcoreaddonsplugin, kio, > kquickcontrolsprivateplugin, and kquickcontrolsaddonsplugin) are being built > as shared libraries. They should be built as bundles (MODULE) in the > CMakeLists.txt file. > > When built as SHARED as in the current code, libdraganddropplugin.dylib gets > installed to $PREFIX/share/qt5/qml/org/kde/draganddrop, but is given an OS X > install_name of $PREFIX/lib/libdraganddropplugin.dylib. This mismatch can > cause problems. It is also given a compatibility_version of 0.0.0. > > > Diffs > ----- > > src/qmlcontrols/draganddrop/CMakeLists.txt e8127e4 > src/qmlcontrols/kcoreaddons/CMakeLists.txt 3f77f2d > src/qmlcontrols/kioplugin/CMakeLists.txt 7b258e0 > src/qmlcontrols/kquickcontrols/private/CMakeLists.txt da355c1 > src/qmlcontrols/kquickcontrolsaddons/CMakeLists.txt 5b711e1 > > Diff: https://git.reviewboard.kde.org/r/124892/diff/ > > > Testing > ------- > > Since the plugin is not supposed to be a linkable library, it should be built > as MODULE in CMakeLists.txt. The physical install location remains the same > and plugins don't have install_names. This corrects the install_name/install > location mismatch. The change should not have any effect on non-OS X systems. > > > Thanks, > > Hanspeter Niederstrasser > >
_______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem