Thread

Re: Broken build on macOS (Universal / Intel): cpuid instruction not available

Tom Lane <tgl@sss.pgh.pa.us> — 2026-05-07T15:48:04Z

Jakob Egger <jakob@eggerapps.at> writes:
> Universal builds are broken since this commit:
> 16743db: Centralize detection of x86 CPU features

> To reproduce:

> export CFLAGS="-arch arm64 -arch x86_64"
> ./configure --without-icu
> make

> This results in an error "cpuid instruction not available"

I can reproduce this here.  But after looking at it briefly,
I think it's purely accidental that universal builds ever worked,
and they could have done so only for small values of "work".

The fundamental problem is that we make only one probe at
configure time to set flags such as HAVE__GET_CPUID.
With a single arch selected in CFLAGS, you get the appropriate
answer for that arch, and everything's fine.  With both selected,
one build or the other will fail such probes with errors like

In file included from conftest.c:135:
/Library/Developer/CommandLineTools/usr/lib/clang/21/include/cpuid.h:14:2: erro\
r: this header is for x86 only
   14 | #error this header is for x86 only
      |  ^

so that we end up with essentially no CPU-specific optimizations
enabled.  That's not a place that you really want to be.  (I've
not checked into how s_lock.h manages to work at all under these
conditions, but maybe it ends up picking a compiler-intrinsic
implementation?)

The proximate reason that it broke is that v18 and before had
code like

#ifdef HAVE_X86_64_POPCNTQ
#if defined(HAVE__GET_CPUID) || defined(HAVE__CPUID)
#define TRY_POPCNT_X86_64 1
#endif
#endif

and didn't try to compile the cpuid-dependent function unless
TRY_POPCNT_X86_64 was set.  The code in HEAD doesn't have
that guard, and is essentially assuming that every x86 platform
wil provide HAVE__GET_CPUID or HAVE__CPUID.

To make this actually work well, we'd have to do two sets of configure
probes, one for each arch, and somehow apply the correct set of
#defines depending on arch.  That's a lot of work that I personally
have no interest in doing, seeing that the handwriting is on the wall
for Apple's support of x86.

I wonder whether we shouldn't just disclaim support for multi-arch
builds.  If it's easy to un-break, then sure we might as well restore
the status quo ante, but I don't think it's worth putting a ton of
work into.

			regards, tom lane