Review Request 126161: OS X housekeeping

[René J.V. Bertin]

On Thursday November 26 2015 08:54:25 David Faure wrote:

> But my point is exactly that: if fork+dlopen is a problem on OSX, then don't do it, do fork+exec. That's what you do,
> but then why exec something that will dlopen, instead of exec the real thing?

Indeed, it's fork+dlopen that is the problem:

`kwrapper5 /path/to/kwrite` succeeds without my helper, whereas
`kwrapper5 /path/to/libkdeinit4_kwrite.dylib` (sic!) crashes during `l.load`.

Evidently there is no choice but to use my helper if kdeinit5 and/or kwrapper5 are supposed to be able to launch() shared libraries containing kdeinitmain or kdemain.
The question is, are they, or is that guaranteed *never* to happen?

Note that I could not reproduce the absence of the standalone kwrite process in `ps` output, with your fix. It does however show up without name in the Activity Monitor, which is kind of an annoyance. Using [[NSProcessInfo processInfo] setProcessName:@"foo"] might be resolve that (requiring an additional ObjC++ module, OR a dedicated kinit_mac.mm). I'd have to check though whether this is not a KDE4/Qt4 issue because I've been annoyed at the fact that those apps tend to show up as mystery entries in certain listings.

R