Issues on OS X: about the kde4_add_plugin macro, and shared vs. module building

[René J.V. Bertin]

Hello,

I should have CC'ed the message below to this list.
Since I didn't, let me signal another issue that hasn't been resolved since I reported it during beta testing:

Karbon and CalligraFlow are still "interchanged" when I build the full suite. Launching the Karbon executable in fact loads the Flow component, and vice versa. I have no idea how to correct that.

%> /Applications/MacPorts/KDE4/karbon.app/Contents/MacOS/karbon
karbon(16546)/koffice (lib komain) KoDocumentEntry::query: KoDocumentEntry::query  "application/vnd.oasis.opendocument.graphics"  got  2  offers! 
"Calligra Flowchart & Diagram Editing Component" 
"Calligra Scalable Graphics Component" 
karbon(16546)/koffice (lib komain) KoDocumentEntry::query: KoDocumentEntry::query  "application/vnd.oasis.opendocument.graphics"  got  2  offers! 
"Calligra Flowchart & Diagram Editing Component" 
"Calligra Scalable Graphics Component" 
2015-03-08 12:30:34.752 karbon[16546:303] modalSession has been exited prematurely - check for a reentrant call to endModalSession:
%> /Applications/MacPorts/KDE4/calligraflow.app/Contents/MacOS/calligraflow
flow(16553)/koffice (lib komain) KoDocumentEntry::query: KoDocumentEntry::query  "application/vnd.oasis.opendocument.graphics"  got  2  offers! 
"Calligra Flowchart & Diagram Editing Component" 
"Calligra Scalable Graphics Component" 
flow(16553)/koffice (lib komain) KoDocumentEntry::query: KoDocumentEntry::query  "application/vnd.oasis.opendocument.graphics"  got  2  offers! 
"Calligra Flowchart & Diagram Editing Component" 
"Calligra Scalable Graphics Component" 
flow(16553)/kdeui (KAction) KActionCollection::setComponentData: this does not work on a KActionCollection containing actions! 

** (process:16553): WARNING **: 1 dictionaries weren't free'd.

Regards,
René

----------  Forwarded Message  ----------

Subject: about the kde4_add_plugin macro, and shared vs. module building
Date: Saturday March 07 2015, 20:28:39
From: René J.V. Bertin <rjvbertin at gmail.com>
To: KDE-MAC ML <kde-mac at kde.org>, David Faure <faure at kde.org>, 'Ben Cooksley' <bcooksley at kde.org>, nicos at macports.org <nicos at macports.org>

Hello,

A while back I ran into an issue building Calligra, which uses 2 of its plugins as shared libraries to link test applications with. The kde4_add_plugin macro causes cmake to create a "shared module" if no other options are given, and on OS X that means code is compiled with `-bundle` (and possibly linked with `-bundle_loader`).

Plugins will work fine when they're built as regular shared libraries (as on Linux), so my first approach was to patch CMake so that KDE4 plugins are built that way. It took almost a year, but I did run into an issue with that approach: the aforementioned -bundle_loader flag can only be used on code compiled with -bundle (`-bundle_loader foo` tells the linker that the plugin is allowed access to foo's symbols, basically).

The easiest way out for the 2 Calligra plugins would be to use

kde4_add_plugin(foo SHARED ...)

but that means we get ${prefix}/lib/foo.dylib instead of ${prefix}/lib/kde4/foo.so, undoubtedly leading to plugin loading failure.

I've never yet had to dirty my hands trying to tweak things at this level. I know MacPorts has patches that changes the extension on certain binary object (from .dylib to .so or vice versa) but that's about all I know.

Does anyone have a suggestion what would be the best solution here? The easiest way would be not to build the 2 test cases, but I'd like something a bit more fundamental, because one day or another we'll bump into a case where a plugin is also used as a shared library for something more important than a test executable.

Or is this kind of "abuse" officially "not done"?

Thanks,
René
-----------------------------------------