Review Request 126161: OS X housekeeping

[David Faure]

On Thursday 26 November 2015 10:27:31 René J.V. Bertin wrote:
> Yes, the *helper* does that, from within the newly exec'ed process. It's weird, but apparently the exact "forbidden" thing is "fork - call/load non-POSIX APIs - exec" while "fork - exec - call/load non-POSIX APIs" works.

That confirms my point. fork+dlopen is forbidden, while fork+exec is OK -- whether that means exec kwrite or exec the helper proxy.

> >I don't understand the difference between "execute kwrite" and "execute a proxy executable that dlopens kwrite".
> 
> Maybe the above helps a wee bit?

No it doesn't. It's fork+exec in both cases, both should work.

> Ah. Indeed, we have NOT tried the simple fork+dlopen approach, for some reason (your patch skips the `l.load()` step).

Don't, it's the thing that kdeinit was doing initially (since it's what it does on linux, whenever possible, i.e. when a .so is found) and which created problems on OSX.

> What's the difference between starting kwrite directly on the commandline (or through execve()), and dlopen'ing it? 

On Linux: it skips the cost of relocations which happen when starting a new binary. kdeinit already links to the major shared
libraries, so it's faster to fork and dlopen.

On OSX: it falls into the forbidden case.

> ... if kdeinit5 and/or kwrapper5 are supposed to be able to launch() shared libraries containing kdeinitmain or kdemain.

You seem to be missing one point: every application which provides a .so ("kdeinit module") *also* provides a binary, always.
The kdeinit module is only an optimization. Every app needs to have a standard executable, for other means of starting it.
The entry point into kdeinit is "start kwrite please". kdeinit decides whether to do that using the kdeinit module (.so) or the executable.
So it's perfectly fine to only support executables. That's also what happens on Windows.
I never realized you could pass a shared lib to kwrapper5, that is definitely not the intended usage, and I can tell you, nobody does this ;)

 > That appears to be the case indeed: `kwrapper5 /path/to/kwrite` is faster than `kwrapper5 /path/to/libkdeinit4_kwrite.dylib`.
 > A bit surprising, because someone still has to open that dylib even when exec'ing `kwrite` ... am I missing something?

Yes but I bet it means some symbol lookups happen at runtime rather than at link time. I'm not enough of a lowlevel
mac toolchain expert to give a fully satisfying explanation, but I'm not very surprised.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5