Re: How to find the architecture for a mach-o file?
Re: How to find the architecture for a mach-o file?
- Subject: Re: How to find the architecture for a mach-o file?
- From: "Karan, Cem (Civ, ARL/CISD)" <email@hidden>
- Date: Wed, 25 Mar 2009 14:41:02 -0400
- 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 <email@hidden>
> 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden