Skip to content

Simplify handling of clang targets, fix clang build on aarch64 and riscv64#15039

Open
belegdol wants to merge 1 commit intomamedev:masterfrom
belegdol:clang_aarch64_riscv64
Open

Simplify handling of clang targets, fix clang build on aarch64 and riscv64#15039
belegdol wants to merge 1 commit intomamedev:masterfrom
belegdol:clang_aarch64_riscv64

Conversation

@belegdol
Copy link
Contributor

@belegdol belegdol commented Mar 1, 2026

This PR fixes building on riscv64 and aarch64 using clang by ensuring -m64 is getting passed instead of -m32.
I am not quite happy with the amount of copy-paste needed. The issue is that gcc does not support -m64 parameter on aarch64 or riscv64, meaning that the ARCHITECTURE parameter needs to be set to an empty value in order to prevent genie from adding the parameter to the generated makefiles.
Unfortunately, clang logic relies on ARCHITECTURE being set to x64 in order to pick the 64-bit config, and falls back to 32-bit target otherwise. While clang does support -m32 and -m64 on aarch64 and riscv64, it does not help if we end up picking the wrong one.
I can think of the following alternative approaches:

  1. Set ARCHITECTURE to blank after the clang logic block
  2. Explicitly check for x86 and only pick the 32-bit target if it is found, fall back to 64-bit otherwise. This might make sense given where 32-bit support is these days in general.

Input is welcome.

@cuavas
Copy link
Member

cuavas commented Mar 2, 2026

AArch64 is ARM64. Why are we back to the situation where different distros call the same target different things, like x64 (Windows) vs x86_64 (most Linux, macOS) vs amd64 (some BSDs)? We’re already building with clang on AArch64 for macOS and Windows at least, so the logic works for those targets.

The whole ARCHITECTURE thing is a mess. I wish there was a better way to debug make files to trace which lines get evaluated, because one way or another the current logic is working for clang ARM64 builds on macOS and Windows. We definitely don’t need an artificial “aarch64” that’s different to “arm64” anyway.

@cuavas
Copy link
Member

cuavas commented Mar 2, 2026

Linux didn’t have an _arm64_clang target like macOS and OpenBSD had, so I added it in daf6833, as well as copying some of the uname parsing logic from higher up in the file.

@belegdol
Copy link
Contributor Author

belegdol commented Mar 2, 2026

Maybe we can at least reduce the amount of copy paste. Genie only supports three targets for GCC: native, x32 and x64. So if there are no differences between the different 32 and 64bit targets, maybe it would be possible to have different variants have fewer results:

Native = {
cppflags = "-MMD -MP",
},
x32 = {
cppflags = "-MMD -MP",
flags = "-m32",
},
x64 = {
cppflags = "-MMD -MP",
flags = "-m64",
},

@belegdol belegdol force-pushed the clang_aarch64_riscv64 branch from 104c4b6 to ea691fa Compare March 3, 2026 08:23
@belegdol belegdol marked this pull request as draft March 3, 2026 08:23
Simplify clang handling by appending _clang suffix to the existing
ARCHITECTURE value instead of attempting to recreate the logic already
existing earlier in the makefile.
While this eliminates the arm64_clang targets, these appear to be an
exact copy of the existing x64 ones and genie only supports native, x86
and x64 configs anyway.
@belegdol belegdol force-pushed the clang_aarch64_riscv64 branch from ea691fa to a28bf9f Compare March 3, 2026 09:58
@belegdol belegdol changed the title Fix clang build on aarch64 and riscv64 Simplify handling of clang targets, fix clang build on aarch64 and riscv64 Mar 3, 2026
@belegdol belegdol marked this pull request as ready for review March 3, 2026 09:59
@belegdol
Copy link
Contributor Author

belegdol commented Mar 3, 2026

This is now less eyesore-inducing. I have tested on Fedora with x86_64, aarch64 and riscv64, each with gcc and clang. Compilation appears to proceed fine. Let's wait for CI to finish to see how other configs fare.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants