python/cpython · error · ValueError
Don't know machine value for archs=%r
Error message
Don't know machine value for archs=%r
What it means
Raised in _osx_support while normalizing the macOS machine/platform name from the ARCHFLAGS architecture list. Only a fixed table of architecture tuples maps to a machine value — ('arm64','x86_64') -> universal2, ('i386','ppc') -> fat, ('i386','x86_64') -> intel, ('i386','ppc','x86_64') -> fat3, ('ppc64','x86_64') -> fat64, ('i386','ppc','ppc64','x86_64') -> universal. Any other combination raises ValueError('Don't know machine value for archs=%r'). It guards against unsupported universal-build architecture sets.
Source
Thrown at Lib/_osx_support.py:562
archs = re.findall(r'-arch\s+(\S+)', cflags)
archs = tuple(sorted(set(archs)))
if len(archs) == 1:
machine = archs[0]
elif archs == ('arm64', 'x86_64'):
machine = 'universal2'
elif archs == ('i386', 'ppc'):
machine = 'fat'
elif archs == ('i386', 'x86_64'):
machine = 'intel'
elif archs == ('i386', 'ppc', 'x86_64'):
machine = 'fat3'
elif archs == ('ppc64', 'x86_64'):
machine = 'fat64'
elif archs == ('i386', 'ppc', 'ppc64', 'x86_64'):
machine = 'universal'
else:
raise ValueError(
"Don't know machine value for archs=%r" % (archs,))
elif machine == 'i386':
# On OSX the machine type returned by uname is always the
# 32-bit variant, even if the executable architecture is
# the 64-bit variant
if sys.maxsize >= 2**32:
machine = 'x86_64'
elif machine in ('PowerPC', 'Power_Macintosh'):
# Pick a sane name for the PPC architecture.
# See 'i386' case
if sys.maxsize >= 2**32:
machine = 'ppc64'
else:
machine = 'ppc'
return (osname, release, machine)View on GitHub (pinned to bc6749cc3b)
Solutions
- Unset ARCHFLAGS and let the build use the interpreter's defaults: `unset ARCHFLAGS`
- If you must pin arches, use a supported set: ARCHFLAGS='-arch arm64 -arch x86_64' (universal2) or a single '-arch arm64' / '-arch x86_64'
- Check for stray whitespace/duplicates/order variations in ARCHFLAGS and normalize the tuple
- Upgrade setuptools/pip so platform detection uses current macOS logic instead of stale vendored copies
Example fix
# before export ARCHFLAGS='-arch i386 -arch ppc -arch arm64' # ValueError # after unset ARCHFLAGS # or a supported combination: export ARCHFLAGS='-arch arm64 -arch x86_64'
Defensive patterns
Strategy: validation
Validate before calling
SUPPORTED = {
('arm64', 'x86_64'), ('i386', 'ppc'), ('i386', 'x86_64'),
('i386', 'ppc', 'x86_64'), ('ppc64', 'x86_64'),
('i386', 'ppc', 'ppc64', 'x86_64'),
}
def validate_archflags(archflags: str) -> None:
import shlex
archs = tuple(a for a in shlex.split(archflags) if a == '-arch') and tuple(
shlex.split(archflags)[i + 1] for i, a in enumerate(shlex.split(archflags)) if a == '-arch'
) or ()
if archs and archs not in SUPPORTED:
raise ValueError(f'Unsupported ARCHFLAGS arch set {archs}; use e.g. arm64+x86_64 or unset ARCHFLAGS') Prevention
- Leave ARCHFLAGS unset unless you specifically need a universal build
- If pinning arches, restrict to single-arch or the universal2 pair arm64+x86_64
- Validate ARCHFLAGS at the top of macOS CI jobs, not mid-build
- Keep macOS build scripts on recent pip/setuptools so platform detection matches current arch tables
When it happens
Trigger: Setting the ARCHFLAGS environment variable to an architecture combination outside the supported table — e.g. ARCHFLAGS='-arch ppc -arch arm64', a single legacy arch like '-arch ppc7400', or a reordered/duplicated set like 'arm64 arm64 x86_64' — then triggering platform/compiler customization (building extensions, sysconfig.get_platform() on macOS).
Common situations: ARCHFLAGS copied from old build docs or a Linux CI script; cross-compile experiments mixing ppc with modern arm64; fat-binary instructions from the PowerPC era; ARCHFLAGS inherited from a shell profile across macOS upgrades; single-arch values that don't hit the x86_64 default path.
Related errors
- Cannot locate working compiler
- Python ssl module is not available
- posix_spawnattr_setbinpref failed to copy\n
- terminal doesn't have the required {cap} capability
- stdlib ssl module not available
AI-assisted analysis of python/cpython@bc6749cc3b (2026-08-14).
Data as JSON: /api/errors/2eebe3ec7a3f78bd.
Report an issue: GitHub.