[KDE/Mac] OSX/CI: okular fails to build on branch frameworks

[Marko Käning]

Hi René,

On 12 Apr 2015, at 16:34 , René J.V. Bertin <rjvbertin at gmail.com> wrote:
> Honestly, this is actually up to the Okular devs to rectify.

you’re right.


> IIRC this is also what the Calligra devs did with the one test app that did this.

They rectified something? Do you have a link to the commit?


> I think that either you patch out the 2 (?) tests, or you add a line that creates
> a proper shared library from the same files as the plugin, and link the test apps
> against that.

Oh well, I don’t think that this is me who’s going to do that in the near future.
I am too busy right now to fix other people’s projects. I think highlighting issues
has been (for a year now) and still will be (for some months to come) enough and
more than I should do (in an ideal world).


> FYI: the same issue will (very likely) occur when building on MS Windows.

I hope it will, as this might speed up fixing the issue also on OSX! ;-)


> IIRC plugins are "more different" from shared libraries there than they are on
> OS X. In fact, OS X allows to use shared libraries as plugins just as Linux does,
> but has an additional type ("bundle") which is meant to be used as a loadable
> module. The difference is in symbol visibility; bundles can have access to all
> symbols from a designated "bundle loader" (= host app) and apparently lack
> information required by the link editor (ld).

Interesting. Well, I know that kdots - for instance - also uses plugins, which are
actually dylibs:
---
$ tree /opt/kde/install/darwin/mavericks/clang/kf5-qt5/kdereview/kdots/inst/
...
├── lib
│   ├── cmake
│   │   └── KDotsLib
│   │       └── KDotsLibConfig.cmake
│   ├── libkdotslib.0.5.4.dylib
│   ├── libkdotslib.1.dylib -> libkdotslib.0.5.4.dylib
│   ├── libkdotslib.dylib -> libkdotslib.1.dylib
...
---

So, why doesn’t or can’t okular do it following it those lines?

Greets,
Marko