The first part of this document describes issues you should consider when bringing code to a 64-bit architecture. You should read through those chapters before you compile your code for the first time, to help you determine whether the compiler warnings are useful or relevant (and possibly do an initial code scrub to look for common errors).
After you have read those chapters, it's time to compile your code with a 64-bit target architecture. You can either compile your code directly (using GCC) or through Xcode. This chapter takes you through the process of setting up your build environment for 64-bit compilation.
For the most part, compiling 64-bit code using GCC works the same way as compiling 32-bit code; there are a few exceptions, however:
You must use GCC 4.0 or later. To choose a GCC version to be used when typing gcc
on the command line, type gcc_select 4.0
. To change the GCC version to be used in Xcode, see “Compiling 64-Bit Code Using Xcode.”
You should turn on the -Wall
flag (and possibly the -Wconversion
flag if you are debugging conversion problems) in order to get additional warnings about potential pointer truncation and other issues.
You must specify a 64-bit architecture (PPC64 or x86-64) with -arch ppc64
or -arch x86_64
. You can also compile binaries with multiple architectures, such as -arch ppc -arch ppc64 -arch x86_64
.
In addition to these exceptions, there are a few new flags and features added for 64-bit architectures. Also, a few flags are not available for 64-bit architectures. The key differences are described in the next section.
Several flags related to 64-bit architectures have been added or modified in GCC:
-arch ppc64
The 64-bit PowerPC architecture option.
-arch x86_64
The 64-bit x86 architecture option.
-mmacosx-version-min=10.5
In addition to its usual function, this flag edits PowerPC linker behavior to enforce a 4 GB “page zero” size. (By default, all 64-bit Intel executables have a 4 GB page zero.) Thus, if you compile your application with this flag, the lower 4 GB of the address space of your process will be empty and will be protected against reading or writing.
As a special exception, any code generated by compiling with -mdynamic-no-pic
on PowerPC is located within the lower 2 GB. This exception applies only to the code itself, not data used by the code.
By using this flag, any code that is not 64-bit clean becomes immediately obvious. As soon as the upper portion of a pointer is zeroed, any attempt to dereference that pointer fails because the access will fall within the now-protected page zero.
In addition, this flag changes the CPU subtype of the resulting executable to prevent execution of the 64-bit portion on a Mac OS X v10.4 system.
Warning: In some versions of the developer tools, the -mmacosx-version-min
flag is set to version 10.4 by default. You must explicitly set a 10.5 minimum deployment target in Xcode when compiling a 64-bit application. If you do not, the application will crash when run on a 64-bit-capable Mac OS X v10.4 system.
To use a different value for the 64-bit slice of your application, read “Using Architecture-Specific Flags.”
-Wconversion
Although not technically new for 64-bit architectures, this option is mostly useful when transitioning 32-bit code to 64-bit. This flag causes additional warnings to be printed when certain conversions occur between data types of different sizes. Most of these warnings will not be useful, so you should not necessarily fix everything that generates a warning with this flag. However, you may sometimes find this flag useful for tracking down hard-to-find edge cases.
In particular, this flag can also help track down edge cases in which a series of legal conversions result in an illegal conversion. For example, with this flag, the compiler will issue a warning if you assign a pointer to a 64-bit integer, pass that pointer into a 32-bit function argument, and subsequently convert the 64-bit function result back into a pointer.
Of course, this flag also produces numerous unexpected warnings that are harmless. For example, in ANSI C, a character literal (for example, 'c'
) is of type int
, so passing it to a function that takes type char
gives a truncation warning. Although the warning is pedantically correct, it is largely irrelevant. You’ll have to sort through all these warnings by hand and determine which ones are legitimate and which ones are fiction.
-Wformat
While not a 64-bit-specific flag, this flag will help you catch mistakes in format arguments to printf
, sprintf
, and similar functions. This flag is turned on by default if you use the -Wall
flag.
-Wshorten-64-to-32
This flag is like -Wconversion
, but is specific to 64-bit data types. This flag causes GCC to issue a warning whenever a value is implicitly converted (truncated) from a 64-bit type to a 32-bit type. You should fix any warnings generated by this flag, as they are likely to be bugs.
In addition, the following flags are highly recommended:
-Wall
Turns on a lot of generally useful warnings.
-Wimplicit-function-declaration
Warns if a function is used prior to its declaration. This can help catch many mistakes caused by differing sizes of function arguments and return types.
This section explains how to get started compiling 64-bit code using Xcode. These instructions assume that you have already installed the necessary command-line components—that is, a 64-bit–aware version of the compiler, linker, assembler, and other low-level tools.
With Xcode 1.0 and later, you can build multiarchitecture binaries (MABs). Because each target can define the set of architectures for the target being built, you can disallow architectures on a per-target basis. You might, for example, choose to build a target with a reduced list of architectures if the target contains assembler code for a particular processor or is not 64-bit-clean.
Each time you run the command-line tool xcodebuild
, you can specify which target architectures to build. You can also configure a "build style" to build a particular set of architectures from within Xcode.
Xcode then builds the target for each of the architectures specified, skipping any architectures that the target does not support. If the target doesn't support any of the specified architectures, that target is skipped entirely.
The build setting VALID_ARCHS
defines the architectures for which a given target can be built. This setting should contain a list of architectures separated by spaces. For example, to specify that your target can be built for ppc
, ppc64
, i386
, and x86_64
, set VALID_ARCHS
to "ppc ppc64 i386 x86_64"
(without the quotes) in the Xcode inspector for your target.
The build setting ARCHS
defines the architectures for which the entire project should be built. This setting should also contain a space-delimited list of architectures. This build setting can be defined either on the command-line to xcodebuild
, or in a build style in Xcode.
For example, to build your project for both 32-bit and 64-bit architectures, type:
xcodebuild ARCHS="ppc ppc64 i386 x86_64" |
You can also set ARCHS="ppc ppc64 i386 x86_64"
in a build style in your project. Similarly, if you want to build only a 64-bit version, specify ARCHS="ppc64 x86_64"
.
If your source code includes special 64-bit versions of framework headers or library headers, you may need to add search paths to the Header Search Paths and Framework Search Paths build settings in the target inspector.
If you are building a target for more than one architecture at the same time, you will see each source file being compiled more than once. This is normal behavior. Xcode compiles each source file once for each architecture so that you can pass different compiler flags for each architecture. The files are glued together at the end of compilation using lipo
. For more information, see lipo
.
Normally, any build settings you specify in the target inspector are used for all architectures for which the target is built. In many cases, however, you need to specify different flags for 64-bit architectures.
If you want to specify additional per-architecture compiler flags, you can use the PER_ARCH_CFLAGS_
<arch> family of build settings, where <arch> is the name of the architecture. For example, to specify compiler flags that apply only to 64-bit PowerPC compilation, add them to the PER_ARCH_CFLAGS_ppc64
build setting.
For example, if you want to make your 64-bit slice run only on Mac OS X v10.6 instead of v10.5, you could set a per-architecture value for “Mac OS X Deployment Target”:
Click the target and choose “Get Info” from the File menu.
Click “Mac OS X Deployment Target”.
Click the gear at the lower left corner of the info window and choose “Add Build Condition Setting” from the resulting pop-up menu.
Change the architecture to “Intel 64-bit” and specify the x86-64 setting for this option.
Add additional conditions as needed for additional architectures.
Change the main setting (above the constrained settings) to whatever you want the default value to be.
Mac OS X v10.4 supports some 64-bit executables. However, Mac OS X v10.4 does not include a full 64-bit stack; Mac OS X v10.4 contains only libSystem
and the Accelerate framework in 64-bit versions. In addition, Mac OS X 10.4 includes neither the Objective-C runtime nor a 64-bit Objective-C-capable version of dyld
. Because of these differences, if you try to execute a 64-bit executable in 10.4 that depends on these 10.5-specific features, it would crash.
To prevent new 64-bit executables from running as 64-bit on version 10.4, Apple changed the CPU subtype for 64-bit executables that depend on high-level frameworks.
If you need to compile an executable as 64-bit for Mac OS X v10.4, you must select the 10.4 deployment target when building 64-bit executables and separate your code into a 32-bit front-end (GUI) portion and a 64-bit back-end (processing) portion.
Last updated: 2010-01-15