Re: Universal binary with different deployment targets - how?
Re: Universal binary with different deployment targets - how?
- Subject: Re: Universal binary with different deployment targets - how?
- From: Greg Guerin <email@hidden>
- Date: Sat, 8 Aug 2009 13:42:01 -0700
Roni Music wrote:
it's a compile time choice
compare to compiling for ppc or intel processor
Instead of comparing to completely different archs like ppc vs.
intel, compare it to slightly different archs like ppc vs ppc7400 or
ppc7450. Or consider the even older PPC variants: 604, 604e. These
are all fundamentally the same architecture, PowerPC, but there are
slight variants of the code each could execute, or variations in the
order of compiled instructions that give best performance on each
arch sub-type.
Ideally, this *would* be an entirely compile-time choice. But if you
can't get that option using fat binaries (for whatever reason), then
your only remaining option is to compile for both arm6 and arm7.
You'd have to use distinct symbol names for each arch, and then point
a function-pointer at the correct version for the arch actually
detected at runtime.
You can also setup a static array of function-pointers (one array per
arch variant) and point one pointer to the base of either array.
This simplifies the runtime choice-making code because only one
pointer changes: the array base pointer.
you guess may be correct but in my opionion is wrong, it works fine
and other developpers see the same problem
and the Apple sengineers states it works fine (which it does)
the problem is that the AppStore/iTunnesConnect people claims it's
not OK
(I think they are missinformed)
Your options appear to be:
1. Pursue a policy solution: File a bug against the AppStore. The
bug is that it forbids uploads containing fat-binaries before OS 3.0,
even though your testing demonstrates that fat binaries work befor OS
3.0, and Apple engineers also say that it works. There may be a
policy reason for this, or it may just be an earlier restriction that
can be lifted with no ill consequences.
2. Pursue a technical solution: Avoid the fat-binary issue entirely
by recoding your app to use function pointers that refer to either
arm6-compiled code or arm7-compiled code. You would then have to
compile your arch-sensitive code twice (separately compiled static
libs), with distinct symbol-names for arm6 and arm7 versions, so the
function-pointers can be changed to point to the right code at
runtime. This will also increase the code's memory footprint,
because both versions of the code will always be resident.
Personally, I would probably do both. The complaint/bug against the
AppStore is unlikely to be resolved in a timely fashion. That leaves
you with only option #2 for timeliness. The advantage of pursuing
option 2 is that it doesn't depend on option 1 at all. If #1
eventually succeeds in changing the policy, you can change your
source accordingly at that time, and if #1 doesn't succeed or the bug
gets rejected, then your code still runs.
-- GG
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden