[KDE/Mac] Review Request 124892: bug 342962: kdeclarative plugins should be built as a bundle plugin and not a shared library

[Harald Sitter]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20150827/c8706f22/attachment.html>