wrong architecture detected

[simdax]

I'm on a MacOs m1. On this mac, one can switch with rosetta between arm64 and x86 https://vineethbharadwaj.medium.com/m1-mac-switching-terminal-between-x86-64-and-arm64-e45f324184d9

I want to build a project, but meson detect the wrong architecture. arch answers arm64 bu

I have the problem with a simple example, like https://github.com/tiernemi/meson-sample-project

Version: 0.64.0

Any clue? :)

Thanks !

[jpakkane]

What arch is your Python 3 installation? Meson uses the CPU that Python reports and IIRC if you are running an x86_64 Python then it will report that.

[nekopsykose]

someone on some irc channel had the same issue, and it was exactly because python from an old brew install (before it even supported m1) was actually x86_64, and so meson sees that and targets it. just rosetta doing its (quite good) magic :)

[nekopsykose]

i guess there's nothing to fix here, unless meson wants to print a (non-failing?) warning (if even possible), that m1 is detected but detected arch is x86_64

[mathstuf]

Interestingly, I have kind of the reverse issue. I'm running a CI job under arch -x86_64 (since Intel machines are getting towards EOL and we need "oompf" to carry Intel builds over our support windows). Everything is detected just fine, but we end up trying to compile for arm64 and the Intel SSE flags get rejected. It works most of the time, but every week or so there's another instance. Is it possible that meson can generate an -arch flag sometimes and miss it others? It seems plausible that the Intel half of a universal2 build (Xcode toolchain) could also default to arm64, but I feel like I'd be seeing that in more than just meson-using projects (NumPy and Mesa).

Anyways, this issue looks like it rhymes at least; just adding my experience here.

[dcbaker]

@mathstuf If you can get the contents of $builddir/meson-logs/*that would be helpful, there's a lot of debugging info around arch detection that ends up there but not in the terminal.

[mathstuf]

I'll try to keep an eye out for it. Luckily the project is low-traffic and it uses its own build directories. It may be difficult due to the meson pyproject.toml wrapper nuking everything from orbit ASAP, but if Mesa fails, that should persist at least.

[mathstuf]

It happened again!

[CDash logs](https://open.cdash.org/builds/10766976/notes#5634538)

ninja: Entering directory `build'
[1/961] Generating src/compiler/glsl/float64_glsl.h with a custom command
[2/961] Generating src/compiler/glsl/glcpp/glcpp-parse.[ch] with a custom command
[3/961] Generating src/mesa/program/program_parse_tab.[ch] with a custom command
../src/mesa/program/program_parse.y:1810.17-54: warning: unused value: $2
../src/mesa/program/program_parse.y:1813.20-60: warning: unused value: $2
[4/961] Generating src/compiler/glsl/glsl_parser with a custom command
[5/961] Compiling C object src/mesa/libmesa_sse41.a.p/main_sse_minmax.c.o
FAILED: src/mesa/libmesa_sse41.a.p/main_sse_minmax.c.o 
sccache cc -Isrc/mesa/libmesa_sse41.a.p -Isrc/mesa -I../src/mesa -Iinclude -I../include -Isrc -I../src -Isrc/mapi -I../src/mapi -I../src/gallium/include -Isrc/gallium/auxiliary -I../src/gallium/auxiliary -fvisibility=hidden -fdiagnostics-color=always -DNDEBUG -Wall -Winvalid-pch -std=c11 -O3 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS '-DPACKAGE_VERSION="22.3.3"' '-DPACKAGE_BUGREPORT="https://gitlab.freedesktop.org/mesa/mesa/-/issues"' -DHAVE_SWRAST -DBUILDING_MESA -DVIDEO_CODEC_VC1DEC=0 -DVIDEO_CODEC_H264DEC=0 -DVIDEO_CODEC_H264ENC=0 -DVIDEO_CODEC_H265DEC=0 -DVIDEO_CODEC_H265ENC=0 -DENABLE_ST_OMX_BELLAGIO=0 -DENABLE_ST_OMX_TIZONIA=0 -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UNREACHABLE -DHAVE___BUILTIN_TYPES_COMPATIBLE_P -DHAVE_FUNC_ATTRIBUTE_CONST -DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC -DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED -DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT -DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL -DHAVE_FUNC_ATTRIBUTE_NORETURN -DHAVE_FUNC_ATTRIBUTE_VISIBILITY -DHAVE_UINT128 -DUSE_SSE41 -DUSE_GCC_ATOMIC_BUILTINS -DHAS_SCHED_H -DHAVE_SYS_SYSCTL_H -DHAVE_XLOCALE_H -DHAVE_DLFCN_H -DHAVE_SYS_SHM_H -DHAVE_CET_H -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_FLOCK -DHAVE_STRTOK_R -DHAVE_BSD_QSORT_R -DHAVE_STRUCT_TIMESPEC -DHAVE_POSIX_MEMALIGN -DHAVE_DIRENT_D_TYPE -DHAVE_STRTOD_L -DHAVE_DLADDR -DHAVE_ZLIB -DHAVE_COMPRESSION -DHAVE_PTHREAD -DLLVM_AVAILABLE '-DMESA_LLVM_VERSION_STRING="15.0.6"' -DLLVM_IS_SHARED=1 -DDRAW_LLVM_AVAILABLE -DMESA_EXECMEM -DHAVE_LIBUNWIND -DVK_USE_PLATFORM_MACOS_MVK -DVK_USE_PLATFORM_METAL_EXT -DVK_ENABLE_BETA_EXTENSIONS -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -Werror=empty-body -Werror=incompatible-pointer-types -Werror=int-conversion -Wimplicit-fallthrough -Wno-missing-field-initializers -Wno-format-truncation -fno-math-errno -fno-trapping-math -Qunused-arguments -fno-common -Wno-microsoft-enum-value -Wno-unused-function -Werror=format -Wformat-security -Werror=thread-safety -Wno-unused-variable -Wno-unused-but-set-variable -fPIC -mmacosx-version-min=10.13 -Werror=pointer-arith -Werror=vla -Werror=gnu-empty-initializer -msse4.1 -MD -MQ src/mesa/libmesa_sse41.a.p/main_sse_minmax.c.o -MF src/mesa/libmesa_sse41.a.p/main_sse_minmax.c.o.d -o src/mesa/libmesa_sse41.a.p/main_sse_minmax.c.o -c ../src/mesa/main/sse_minmax.c
In file included from ../src/mesa/main/sse_minmax.c:30:
/Applications/Xcode-16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/smmintrin.h:14:2: error: "This header is only meant to be used on x86 and x64 architecture"
   14 | #error "This header is only meant to be used on x86 and x64 architecture"
      |  ^
In file included from ../src/mesa/main/sse_minmax.c:30:
In file included from /Applications/Xcode-16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/smmintrin.h:17:
/Applications/Xcode-16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/tmmintrin.h:14:2: error: "This header is only meant to be used on x86 and x64 architecture"
   14 | #error "This header is only meant to be used on x86 and x64 architecture"
      |  ^
In file included from ../src/mesa/main/sse_minmax.c:30:
In file included from /Applications/Xcode-16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/smmintrin.h:17:
In file included from /Applications/Xcode-16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/tmmintrin.h:17:
/Applications/Xcode-16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/pmmintrin.h:14:2: error: "This header is only meant to be used on x86 and x64 architecture"
   14 | #error "This header is only meant to be used on x86 and x64 architecture"
      |  ^
In file included from ../src/mesa/main/sse_minmax.c:30:
In file included from /Applications/Xcode-16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/smmintrin.h:17:
In file included from /Applications/Xcode-16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/tmmintrin.h:17:
In file included from /Applications/Xcode-16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/pmmintrin.h:17:
/Applications/Xcode-16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/emmintrin.h:14:2: error: "This header is only meant to be used on x86 and x64 architecture"
   14 | #error "This header is only meant to be used on x86 and x64 architecture"
      |  ^
In file included from ../src/mesa/main/sse_minmax.c:30:
In file included from /Applications/Xcode-16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/smmintrin.h:17:
In file included from /Applications/Xcode-16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/tmmintrin.h:17:
In file included from /Applications/Xcode-16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/pmmintrin.h:17:
In file included from /Applications/Xcode-16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/emmintrin.h:17:
/Applications/Xcode-16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/xmmintrin.h:14:2: error: "This header is only meant to be used on x86 and x64 architecture"
   14 | #error "This header is only meant to be used on x86 and x64 architecture"
      |  ^
In file included from ../src/mesa/main/sse_minmax.c:30:
In file included from /Applications/Xcode-16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/smmintrin.h:17:
In file included from /Applications/Xcode-16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/tmmintrin.h:17:
In file included from /Applications/Xcode-16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/pmmintrin.h:17:
In file included from /Applications/Xcode-16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/emmintrin.h:17:
In file included from /Applications/Xcode-16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/xmmintrin.h:17:
/Applications/Xcode-16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/mmintrin.h:14:2: error: "This header is only meant to be used on x86 and x64 architecture"
   14 | #error "This header is only meant to be used on x86 and x64 architecture"
      |  ^
6 errors generated.
[6/961] Generating src/mesa/format_info.h with a custom command (wrapped by meson to capture output)
[7/961] Generating src/mesa/format_fallback.c with a custom command
[8/961] Compiling C object src/compiler/glsl/glcpp/libglcpp.a.p/pp.c.o
[9/961] Generating src/compiler/glsl/ir_expression_operation_strings.h with a custom command (wrapped by meson to capture output)
[10/961] Generating src/compiler/glsl/ir_expression_operation_constant.h with a custom command (wrapped by meson to capture output)
[11/961] Compiling C object src/compiler/glsl/glcpp/libglcpp.a.p/meson-generated_.._glcpp-parse.c.o
src/compiler/glsl/glcpp/glcpp-parse.c:1416:4: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
 1416 |           default:
      |           ^
src/compiler/glsl/glcpp/glcpp-parse.c:1416:4: note: insert '__attribute__((fallthrough));' to silence this warning
 1416 |           default:
      |           ^
      |           __attribute__((fallthrough)); 
src/compiler/glsl/glcpp/glcpp-parse.c:1416:4: note: insert 'break;' to avoid fall-through
 1416 |           default:
      |           ^
      |           break; 
1 warning generated.
[12/961] Generating src/mesa/main/remap_helper.h with a custom command (wrapped by meson to capture output)
[13/961] Generating src/mesa/main/dispatch.h with a custom command (wrapped by meson to capture output)
[14/961] Generating src/mesa/get_hash.h with a custom command (wrapped by meson to capture output)
[15/961] Generating src/mesa/main/marshal_generated.h with a custom command (wrapped by meson to capture output)
[16/961] Generating src/compiler/glsl/glcpp/glcpp-lex.c with a custom command
[17/961] Generating src/mesa/program/mesa_lex with a custom command
[18/961] Generating src/compiler/glsl/glsl_lexer_cpp with a custom command
ninja: build stopped: subcommand failed.

meson-logs/meson-log.txt: molina-intel-issue.log

[eli-schwartz]

https://gitlab.freedesktop.org/mesa/mesa/-/blob/c2a6fb64193f485fde3dea7a6db6eb60d83dc94a/meson.build#L1282

if host_machine.cpu_family().startswith('x86')
  pre_args += '-DUSE_SSE41'
  with_sse41 = true

https://gitlab.freedesktop.org/mesa/mesa/-/blob/c2a6fb64193f485fde3dea7a6db6eb60d83dc94a/src/mesa/meson.build#L437

if with_sse41
  libmesa_sse41 = static_library(
    'mesa_sse41',
    files('main/sse_minmax.c'),
    c_args : [c_msvc_compat_args, sse41_args],
    include_directories : [inc_include, inc_src, inc_mesa, inc_gallium, inc_gallium_aux],
    gnu_symbol_visibility : 'hidden',
  )
else
  libmesa_sse41 = []
endif

[eli-schwartz]

But the compiler is "just" sccache cc?

[mathstuf]

The CI job runs under an arch -x86_64 bash command, so, yes, it is "just" that (with DEVELOPER_DIR set to an Xcode 16.4 installation).

[mathstuf]

So I was staring at the logs and a thought occurred to me: we use sccache which talks to its server over a TCP socket…this is not arch -x86_64-contained if it is persistent from a prior arm64 job that didn't get to the "stop the sccache server" part of its routine. I've deployed a change so that our Rosetta-based runners use an offset TCP port from the native runners. If that stops this from popping up for a few weeks, I'm fine claiming that as a suitable solution.

What it does not explain is why only meson-based builds ended up with this confusion…in a way that killed the builds at least. I suppose I could investigate the rubble from a build job that was in-progress to see if the "x86_64 build" was actually making arm64 object files, but I'd have to catch it in the act again.

[dcbaker]

Meson does specifically query the compiler to see what the actual architecture is on a given machine, since what we would otherwise get is what the python is built for, even though you can run an x86 python on an x86_64 host (for example). I highly suspect that's what's tripping up the code here.

That code is also super fragile and problematic, I've been hitting my head against it a lot recently.

[mathstuf]

Does it query it through any launcher (like sccache) or does it run it directly. CMake does the same, but it skips the wrapper.. Looking at our build scripts…I'm not actually sure how sccache is being picked up by meson in the first place…we only pass it to CMake projects, qt5, and sqlite on Windows…

[mathstuf]

In any case, the architecture detection is working: sse flags are being added but then dying when sccache ends up launching a compiler thinking it is going to do arm64 compilation.

[mathstuf]

Even with per-arch sccache instances, the problem still persists. I suppose the cache could be poisoned though.

[mathstuf]

Ok, false alarm…what I changed was a placebo and actually did nothing. I now have proper changes staged for deployment which will do this, but I need to go and remove some stuff from every project using project-local settings…will have that done once I get a review from anyone else on the deployment changes and merge some project changes to really know.

[mathstuf]

I fixed the changes to actually separate things based on arch. So far so good (was deployed on Friday). If I don't see any instances by next week I'll claim it as a success.

It still doesn't explain why it only showed up for Meson-based projects unless they just happen to be the one using arch-specific flags and it is a sampling bias.