On Jul 3, 2013, at 21:40, Jerry Krinock <[email protected]> wrote: > To answer your question, I think the procedure is… > > * In your main target and its target dependencies, > * Set the SDK to "Latest Mac OS X". > * Set the architecture to x86_64. > * Clean your project, so that everything will be recompiled. > * Analyze your project (⇧⌘B). > > After it's done, look at the newly-produced Build log in the Logs navigator. > Any deprecated or no-longer-existing functions and types should be listed as > warnings and errors. Fix and repeat.
This isn’t a general procedure though. What this does is switch the entire application to be compiled as 64-bit, which just happens to have the side-effect of not supporting most of the deprecated Carbon calls. If your application does any low-level byte manipulation or uses the ‘long’ data type (instead of fixed-size types like UInt32 or int32_t), this will also completely break your code. long is 32 bits on 32-bit, but 64 bits on 64 bit. Pointers will also suddenlt by 64 bits in size. So if you pass any pointers through a refCon or userInfo parameter that happens to be typedefed as UInt32 or so, you’ll be stripping off half the pointer and causing entertaining crashes. Now you’ll have to port to 64-bit eventually anyway, but it might help to first go over your code and look for any longs you’re using and make sure they’re turned into int32_t or uint32_t if they’re supposed to stay 32 bit, or use intptr_t or void* for any types that are supposed to be the size of a pointer. -- Uli _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
