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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
