<div dir="ltr">Ian,<div><br></div><div>I took a look at kdelibs4 in macports and <a href="https://trac.macports.org/browser/trunk/dports/kde/kdelibs4/files/workaround-kdeinit4-crash.patch">https://trac.macports.org/browser/trunk/dports/kde/kdelibs4/files/workaround-kdeinit4-crash.patch</a> looks particularly interesting to what we are trying to fix here. Especially it's use of a separate executable (helperExe) to launch klauncher with. If you think this could be a possible solution I can look into reworking this patch to work with what's in kf5's kinit, with proper #ifdef Q_OS_OSX and such (or once you get qt5 to build you can take a crack at it if you like). What do you think?</div><div><br></div><div>BR,</div><div>Jeremy</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 11, 2015 at 5:29 PM, Ian Wadham <span dir="ltr"><<a href="mailto:iandw.au@gmail.com" target="_blank">iandw.au@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12/02/2015, at 10:34 AM, Brandon Allbery wrote:<br>
> On Wed, Feb 11, 2015 at 6:31 PM, René J.V. <<a href="mailto:rjvbertin@gmail.com">rjvbertin@gmail.com</a>> wrote:<br>
> I take that to mean that doing fork() doesn't oblige you to do an exec() afterwards, it's that you cannot do a fork() from a process that's not been started through exec.<br>
><br>
> I will guess that this is related to the fact that such processes are actually started by launchd, and must play by launchd's rules (including not using fork()) so launchd can keep track of them. This would also imply that fork() is actually acceptable as long as the forked processes don't try to use the UI, but are merely background worker processes that communicate with the foreground process if they need UI interaction or etc.<br>
<br>
</span>FWIW, there is some special code in the main() program of kdeinit5 that<br>
causes it to fork and re-exec *itself* on Apple OS X (the second time with a<br>
--no-fork arg) --- before it goes on to do its main work.<br>
<br>
For more detail, in frameworks/kinit/src/kdeinit/kinit.cpp code, see lines<br>
1705 and 1576ff. The comments at the head of the second reference say:<br>
<br>
/**<br>
Calling CoreFoundation APIs (which is unavoidable in Qt/Mac) has always had issues<br>
on Mac OS X, but as of 10.5 is explicitly disallowed with an exception. As a<br>
result, in the case where we would normally fork and then dlopen code, or continue<br>
to run other code, we must now fork-and-exec.<br>
<br>
See "CoreFoundation and fork()" at <a href="http://developer.apple.com/releasenotes/CoreFoundation/CoreFoundation.html" target="_blank">http://developer.apple.com/releasenotes/CoreFoundation/CoreFoundation.html</a><br>
*/<br>
<br>
When I can get Qt 5 to build and then Frameworks and some KF5 apps, I propose<br>
to start tracking down what is happening on Apple OS X in some of the paths that<br>
kdeinit5 and friends are following, starting with what KToolInvocation is doing in a<br>
few major cases.<br>
<br>
For a rough but obviously now-out-of-date guide see:<br>
<a href="https://techbase.kde.org/Development/Architecture/KDE4/Starting_Other_Programs" target="_blank">https://techbase.kde.org/Development/Architecture/KDE4/Starting_Other_Programs</a><br>
<br>
Cheers, Ian W.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
<a href="mailto:kde-mac@kde.org">kde-mac@kde.org</a><br>
List Information: <a href="https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac" target="_blank">https://mail.kde.org/mailman/listinfo/kde-mac<br>
KDE/Mac</a> Information: <a href="http://community.kde.org/Mac" target="_blank">http://community.kde.org/Mac</a><br>
</div></div></blockquote></div><br></div>