Created attachment 90475 [details]
patch to build plugins as MODULE

Please head to https://git.reviewboard.kde.org/r/ and submit your patch there, patches in bug reports tend to get overlooked, as you might have noticed. Thanks!

https://git.reviewboard.kde.org/r/124892/

Git commit 383aa77ebf0b08adca13ce67a90f61c9c6a65851 by David Edmundson, on behalf of Hanspeter Niederstrasser.
Committed on 23/08/2015 at 21:15.
Pushed by davidedmundson into branch 'master'.

kdeclarative plugins should be built as a bundle plugin and not a shared library

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.
REVIEW: 124892

M  +1    -1    src/qmlcontrols/draganddrop/CMakeLists.txt
M  +1    -1    src/qmlcontrols/kcoreaddons/CMakeLists.txt
M  +1    -1    src/qmlcontrols/kioplugin/CMakeLists.txt
M  +1    -1    src/qmlcontrols/kquickcontrols/private/CMakeLists.txt
M  +1    -1    src/qmlcontrols/kquickcontrolsaddons/CMakeLists.txt

http://commits.kde.org/kdeclarative/383aa77ebf0b08adca13ce67a90f61c9c6a65851

Reverting change as it broke loading on linux. See discussion on reviewboard as well as https://mail.kde.org/pipermail/kde-frameworks-devel/2015-August/026281.html

I'm going to copy here what I wrote on the (now discarded) RR:

> This [install_name] mismatch can cause problems. It is also given a compatibility_version of 0.0.0.

You don't apport any proof that this is actually a bug, so what exactly is this whole affair about? If it's about "these items should always have been built as modules" that's one thing (with a rather high "don't fix it if it ain't broke" factor if you ask me, and not something I'd call a bug at this point) ; claiming it causes issues on an OS where (AFAIK) this cannot even be tested because of more seriously and truly blocking issues is something else all together.

As far as I know, both properties are used only when the dylib is used as a shared library, that is they're only used by the dynamic loader when information to compare them to 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.

I can affirm that this exact same situation does not cause any issues with KDE4 on OS X:

```
> otool -Lv /opt/local/lib/kde4/imports/org/kde/draganddrop/libdraganddropplugin.dylib
/opt/local/lib/kde4/imports/org/kde/draganddrop/libdraganddropplugin.dylib:
        /opt/local/lib/libdraganddropplugin.dylib (compatibility version 0.0.0, current version 0.0.0)
        time stamp 1 Thu Jan  1 01:00:01 1970
        /opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.7)
        time stamp 2 Thu Jan  1 01:00:02 1970
        /opt/local/libexec/qt4/Library/Frameworks/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.7)
        time stamp 2 Thu Jan  1 01:00:02 1970
        /opt/local/libexec/qt4/Library/Frameworks/QtDeclarative.framework/Versions/4/QtDeclarative (compatibility version 4.8.0, current version 4.8.7)
        time stamp 2 Thu Jan  1 01:00:02 1970
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
        time stamp 2 Thu Jan  1 01:00:02 1970
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
        time stamp 2 Thu Jan  1 01:00:02 1970
> dlsym /opt/local/lib/kde4/imports/org/kde/draganddrop/libdraganddropplugin.dylib _ZTI9QMimeData/opt/local/lib/kde4/imports/org/kde/draganddrop/libdraganddropplugin.dylib::_ZTI9QMimeData: 0x1004c0300 (/opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/QtCore::_ZTI9QMimeData)
> demangle _ZTI9QMimeData
_ZTI9QMimeData -> "typeinfo for QMimeData"
```

(So not only the install_name and the compatibility_version info are wrong, the recorded timestamps are bogus too, and yet the module loads fine and `dlsym(draganddrop_handle, "_ZTI9QMimeData")` returns the correct address which is obtained from a shared library linked to the module.)

A little bit of background, FWIW: 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.

Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.