Re: How to find the architecture for a mach-o file?
site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Thread-index: AcmtZfSHtr/EJlg3SsiFSzx0mvU1nQAEsEqA Thread-topic: How to find the architecture for a mach-o file? On Wed, 25 Mar 2009 09:21:42 Terry Lambert wrote:
On Mar 25, 2009, at 8:36 AM, Jonas Maebe <jonas.maebe@elis.ugent.be> wrote:
On 25 Mar 2009, at 16:06, Karan, Cem (Civ, ARL/CISD) wrote:
On 25 Mar 2009, at 12:43, Karan, Cem (Civ, ARL/CISD) wrote:
Using otool -aSfh, I get the following:
Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags 0xfeedface 7 3 0x00 6 11 1208 0x00100085
The problem is that I have no idea what the cputype and subtype numbers mean. Anybody with any ideas? In fact, any ideas on how to fix this problem?
Does <mach/machine.h> help?
Yup, it did! Thanks... although now I'm even more confused than before, because I'm running on a Xeon PowerMac, so the type and subtype should be fine...
That depends on the type and subtype of the application that is trying to open the library.
Plus there are feature bit carve-outs in the bitspace of both the cpu_type and cpu_subtype fields which are ignored for the purposes of comparing them to the results of cpu_type() and cpu_subtype() for the purposes of binary grading.
For example, 64 vs. 32 bit is not returned in the host cpu_type() information, since whether or not you can run 64 bit binaries is orthogonal to architecture. To arrange things otherwise would mean you would't run 32 bit binaries on 64 bit machines, or that whether or not 64 bit binaries are supportable on a given machine was not contollable by a boot argument (it is, and is necessary for comparison testing).
Use the file command vs. Both the library and the thing that it links against, or if you insist on comparing type/subtype fields, do so with both the knowledge that you should ignore the high 8 bits, and that just because there us at least one field that matches does not mean that's the slice that's getting preferentially loaded.
Note that this can particularly be a problem if you link a multiarchitecture binary against a multiarchitecture library then install the binary on a machine where the library installed isn't multiarchitecture. Don't do that.
Another common mistake is to build a debug binary in XCode; then fail to install the release version on the target machine.
Well, the installed version of the dot tool has 4 architectures: ppc i386 64-bit ppc64 64-bit x86_64 The installed expat library comes back as i386. So dyld should be fine, right? Thanks, Cem Karan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com
participants (1)
-
Karan, Cem (Civ, ARL/CISD)