ARCH(1) | General Commands Manual | ARCH(1) |
arch
— print
architecture type or run selected architecture of a universal
binary
arch |
arch |
[-32 ] [-64 ]
[[- arch_name |
-arch arch_name]...]
[-c ] [-d
envname]... [-e
envname=value]... [-h ]
prog [args
...] |
The arch
command with no arguments,
displays the machine's architecture type.
The other use of the arch
command is to
run a selected architecture of a universal binary. A universal binary
contains code that can run on different architectures. By default, the
operating system will select the architecture that most closely matches the
processor type. A 64-bit architecture is preferred over a 32-bit
architecture on a 64-bit processor, while only 32-bit architectures can run
on a 32-bit processor.
When the most natural architecture is unavailable, the operating system will try to pick another architecture. On 64-bit processors, a 32-bit architecture is tried. Otherwise, no architecture is run, and an error results.
The arch
command can be used to alter the
operating system's normal selection order. The most common use is to select
the 32-bit architecture on a 64-bit processor, even if a 64-bit architecture
is available.
The arch_name argument must be one of the currently supported architectures:
If the binary does not contain code for
arch_name, the arch
command
may try to select a close match. If arm64 is specified and not found, arm64e
will be tried next. If this happens, the order the architectures will be
tried is not guaranteed.
Either prefix the architecture with a hyphen, or (for
compatibility with other commands), use -arch
followed by the architecture.
If more than one architecture is specified, the operating system will try each one in order, skipping an architecture that is not supported on the current processor, or is unavailable in the universal binary.
The other options are:
-32
-64
-c
-d
envname-e
envname=value-h
The prog argument is the command to run, followed by any arguments to pass to the command. It can be a full or partial path, while a lone name will be looked up in the user's command search path.
If no architectures are specified on the command line, the
arch
command takes the basename of the
prog argument and searches for the first property list
file with that basename and the .plist suffix, in
the archSettings sub-directory in each of the
standard domains, in the following order:
This property list contains the architecture order preferences, as well as the full path to the real executable. Please refer to the EXAMPLES section for an example of the property list file format.
When a link is made to arch
command with a
different name, that name is used to find the corresponding property list
file. Thus, other commands can be wrapped so that they have custom
architecture selection order.
Because of some internal logic in the code, hard links to the
arch
command may not work quite right. It is best to
avoid using hard links, and only use symbolic links to the
arch
command.
The environment variable ARCHPREFERENCE
can be used to provide architecture order preferences. It is checked before
looking for the corresponding property list file.
The value of the environment variable
ARCHPREFERENCE
is composed of one or more
specifiers, separated by semicolons. A specifier is made up of one, two or
three fields, separated by colons. Architectures specified in order, are
separated by commas and make up the last (mandatory) field. The first field,
if specified, is a name of a program, which selects this specifier if that
name matches the program name in question. If the name field is empty or
there is no name field, the specifier matches any program name. Thus,
ordering of specifiers is important, and the one with no name should be
last.
When the arch
command is called directly,
the prog name provides the path information to the
executable (possibly via the command search path). When a name is specified
in a ARCHPREFERENCE
specifier, the path information
can alternately be specified as a second field following the name. When the
arch
command is called indirectly via a link, this
path information must be specified. If not specified as a second field in a
specifier, the executable path will be looked up in the corresponding
property list file.
This is an example of a property list file as is expected in one of the archSettings locations mentioned above:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>ExecutablePath</key> <string>$execpath</string> <key>PreferredOrder</key> <array> <string>x86_64</string> <string>arm64</string> </array> <key>PropertyListVersion</key> <string>1.0</string> </dict> </plist>
foo
(the full executable path is in the foo.plist
file).baz
and a second specifier that
would match any other name.Running the arch
command on an interpreter
script may not work if the interpreter is a link to the arch command.
February 15, 2021 | macOS 15.0 |