On Oct 27, 2005, at 6:32 PM, Peter Litwinowicz wrote: So I’m trying to create universal binaries that have ppc7400 and ppc970 binaries in the resultant fat binary which is a dynamic library bundle plugin for another app. FYI, we plug into an app that requires G4 support.
This works just great on Mac OS 10.4. The 7400 binary is loaded on G4 machines and the 970 binary is loaded on G5 machines.
However, the app that we plug into is supported on Mac OS 10.3.9 too. Cool enough. For two of my plugin fat binaries when I run ‘lipo –info’ I get
ppc7400 ppc970
And because the ppc7400 is listed first (or so I surmise) then my users 10.3.9 are happy because the “lowest common denominator” code is loaded.
However, for one of my fat binaries when I run lipo I get
ppc970 ppc7400
This means that G4 CPUs running OS 10.3.9 cannot run properly, because it loads the ppc970 binary and promptly displays an error message.
That's interesting...it implies that 10.3.9 isn't picking the best CPU subtype. If this is in a bundle that might be a dyld issue rather than a kernel issue -- in other words, this might be different for bundles versus applications. I’ve tried rearranging my input “thin” binaries when I run “lipo –create PPC7400_BINARY PPC970_binary –output resultBinary” but to know avail.
Is there any way that I can force ‘lipo –create’ to not arbitrarily rearrange my input binaries when creating the output fat binary? lipo should not be rearranging things. If it does, please file a bug report. That said, the Mach-O file format is pretty simple. If you can't find a better solution, it wouldn't be too hard to write your own "lipo" to do exactly this task.
-Eric
|
