[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-mac
Subject:    Re: [KDE/Mac] Review Request 126161: OS X housekeeping
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2015-11-26 13:04:52
Message-ID: 6556358.XIW5pKugdT () portia ! local
[Download RAW message or body]

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-mac@kde.org
List Information: https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac Information: http://community.kde.org/Mac


[prev in list] [next in list] [prev in thread] [next in thread]