Re: sysctl.proc_exec_affinity to force launching of 32-bit flavor?
Re: sysctl.proc_exec_affinity to force launching of 32-bit flavor?
- Subject: Re: sysctl.proc_exec_affinity to force launching of 32-bit flavor?
- From: Eric Gouriou <email@hidden>
- Date: Thu, 12 Mar 2009 18:38:25 -0700
On Mar 12, 2009, at 5:54 AM, Jim Correia wrote:
On Mar 12, 2009, at 6:10 AM, Terry Lambert wrote:
The place where this would be important today is on a machine
capable of running 64 bit Intel binaries, but for which only the
system framework is available, and not other frameworks. Since we
changed the 64 bit binary cpu type number by adding a "has 64 bit
frameworks bit" to it, when we added framework support, if you link
a new binary, the 386 version of the binary is going to be
preferred by the older version of the OS anyway, so you'd be
solving a problem that doesn't exist in the first place.
The other place it could be important is if you ported over your 32
bit KEXT or daemon that talked to it, and decide, for whatever
reason that you wanted to still communicate ponter and long values
between it and user space instead of using sized types.
The other place where I wanted to control this is where my GUI app,
which runs as a 32-bit process on Leopard (which can be influenced
by LSMinimumSystemVersionByArchitecture), launches a helper (today
via exec), and I'd like to run the helper as 32-bit on Leopard too,
mainly because I don't want to be the reason the 64-bit frameworks
are loaded in.
For a drag and drop type install, LIPO isn't an option.
But you could also LIPO at install time with your install tool or
the binary itself when it saw the results of the uname(2) system
call, or you could also write a small script to wrap the use of the
arch(1) command, or you could use the posix_spawn(2) extensions
documented in posix_spawnattr_setbinpref_np(2) to reexec yourself,
if you didn't mind running the 64 bit binary, saying "whoops! I
should be 32 bit!" and restarting yourself with a different
preference.
It looks like using posix_spawn solves the problem. (Previously I
was using fork/exec because the code was originally written to
target 10.4.x.)
In addition to the various solutions offered in this thread...
You can also consider building the various slices of your fat binary
with different -mmacos-version-min settings
so that, e.g., the 64bit slice will only be running on 10.5 while the
32bit slice is allowed on 10.4 .
32b -mmacosx-version-min=10.4
64b -mmacosx-version-min=10.5
Adapt to taste. That's the theory at least, please double-check
before committing to that solution.
Eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden