llvm-mos-sdk build errors on rPi Linux Debian Trixie 64 bit

[PacoPico8788]

I'm attempting to build the llvm-mos-sdk repo - forked into my github 2 weeks ago - on my Raspberry 5 - Linux 6.18.29+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.18.29-1+rpt1 (2026-05-12) aarch64 GNU/Linux - which already contains the build-essential 12.12 install.

I've tried both the manual download of the llvm-mos binary and the 'cmake/bootstrap-compiler.cmake:16 (FetchContent_Declare)' inline method of bootstrapping a local base llvm-mos needed to get on with the llvm-mos-sdk build. Both methods are creating local copies of the clang-23 executable.

However, both attempts fail in early cmake execution where cmake is finding garbage files that the build process seems to be creating. Here is a bit of the cmake log file showing the last attempt which used the 'bootstrap-compiler.cmake' method of getting the llvm-mos environment:

`2026-05-24T19:21:02.206Z [info] [cmake] -- Did not find MOS compiler - Enabling bootstrap download.

2026-05-24T19:21:02.214Z [warning] [cmake] CMake Warning (dev) at /usr/share/cmake-3.31/Modules/FetchContent.cmake:1373 (message):

2026-05-24T19:21:02.214Z [warning] [cmake] The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is

2026-05-24T19:21:02.215Z [warning] [cmake] not set. The policy's OLD behavior will be used. When using a URL

2026-05-24T19:21:02.215Z [warning] [cmake] download, the timestamps of extracted files should preferably be that of

2026-05-24T19:21:02.216Z [warning] [cmake] the time of extraction, otherwise code that depends on the extracted

2026-05-24T19:21:02.217Z [warning] [cmake] contents might not be rebuilt if the URL changes. The OLD behavior

2026-05-24T19:21:02.217Z [warning] [cmake] preserves the timestamps from the archive instead, but this is usually not

2026-05-24T19:21:02.218Z [warning] [cmake] what you want. Update your project to the NEW behavior or specify the

2026-05-24T19:21:02.218Z [warning] [cmake] DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this

2026-05-24T19:21:02.219Z [warning] [cmake] robustness issue.

2026-05-24T19:21:02.219Z [warning] [cmake] Call Stack (most recent call first):

2026-05-24T19:21:02.220Z [warning] [cmake] cmake/bootstrap-compiler.cmake:16 (FetchContent_Declare)

2026-05-24T19:21:02.220Z [warning] [cmake] CMakeLists.txt:34 (include)

2026-05-24T19:21:02.221Z [warning] [cmake] This warning is for project developers. Use -Wno-dev to suppress it.

2026-05-24T19:21:02.221Z [warning] [cmake]

2026-05-24T19:21:02.224Z [warning] [cmake] -- Downloading LLVM-MOS compiler, please wait...

2026-05-24T19:21:02.349Z [warning] [cmake] -- LLVM-MOS compiler downloaded

2026-05-24T19:21:02.358Z [warning] [cmake] /home/fjc/git/rp6502_llvm-mos-sdk/build/_deps/llvm-mos-src/bin/mos-clang: 1: �ELF�����: not found

2026-05-24T19:21:02.362Z [warning] [cmake] /home/fjc/git/rp6502_llvm-mos-sdk/build/_deps/llvm-mos-src/bin/mos-clang: 1: �����������@�-����n��������@�@����p�p�p�00���������DD����: not found

2026-05-24T19:21:02.366Z [warning] [cmake] /home/fjc/git/rp6502_llvm-mos-sdk/build/_deps/llvm-mos-src/bin/mos-clang: 1: �����������8�S�td�p�p�p�00�P�td�����������������Q�td��R�td��: not found

2026-05-24T19:21:02.367Z [warning] [cmake] /home/fjc/git/rp6502_llvm-mos-sdk/build/_deps/llvm-mos-src/bin/mos-clang: 1: ����������h�#h�#�/lib64/ld-linux-x86-64.so.2�: not found

2026-05-24T19:21:02.367Z [warning] [cmake] /home/fjc/git/rp6502_llvm-mos-sdk/build/_deps/llvm-mos-src/bin/mos-clang: 2: Syntax error: word unexpected (expecting ")")

2026-05-24T19:21:02.382Z [warning] [cmake] CMake Error at cmake/find-mos-compiler.cmake:62 (message):

2026-05-24T19:21:02.383Z [warning] [cmake] Unable to target MOS using

2026-05-24T19:21:02.383Z [warning] [cmake] /home/fjc/git/rp6502_llvm-mos-sdk/build/_deps/llvm-mos-src/bin/mos-clang.

2026-05-24T19:21:02.383Z [warning] [cmake] Try setting LLVM_MOS to a directory containing LLVM-MOS clang binary.

2026-05-24T19:21:02.384Z [warning] [cmake] Call Stack (most recent call first):

2026-05-24T19:21:02.384Z [warning] [cmake] CMakeLists.txt:40 (find_mos_compiler)
`

Here is the top layer of the build directory that this round was creating showing a garbage file:

`fjc@fjcP5:~/git/rp6502_llvm-mos-sdk/build $ ls -al

total 40

drwxrwxr-x 5 fjc fjc 4096 May 24 15:43 .drwxrwxr-x 10 fjc fjc 4096 May 24 15:38 ..

-rw-rw-r-- 1 fjc fjc 0 May 24 15:21 ''$'\001\340\020\310''@'$'\270\276\257\004''@8'$'\016''@'

drwxrwxr-x 3 fjc fjc 4096 May 24 15:11 .cmake

-rw-rw-r-- 1 fjc fjc 17345 May 24 15:20 CMakeCache.txt

drwxrwxr-x 4 fjc fjc 4096 May 24 15:21 CMakeFiles

drwxrwxr-x 5 fjc fjc 4096 May 24 15:12 _deps
`

I did find a message online saying that llvm-mos-sdk requires the exact same version of llvm-mos in order to succeed and that there is very recent activity in both the picocomputer and the llvm-mos repo's. I haven't yet found where the version of the picocomputer llvm-mos-sdk is defined but I am still looking.

Has anyone else seen/heard of this type of issue?

Thanks,
Frank C

[rumbledethumps]

Our changes are pretty far away from whatever is causing your issue. I would ask the LLVM-MOS folks directly: https://discord.gg/D9gRm3aznh

At first glance, it looks like there's no binary in the path so it's downloading something and trying to find x64 files on your arm system. Maybe that helps, but it leaves me confused.

[PacoPico8788]

Will do and thank you very much!

[gistrec]

Adding a concrete workaround to the maintainer's diagnosis: this does look like an architecture mismatch. The bootstrap is downloading a prebuilt Linux mos-clang that is not runnable on the Pi's aarch64 userspace. The garbled bytes are likely the ELF header being parsed by the shell after the kernel fails to execute the binary.

Two things make this happen:

1. cmake/bootstrap-compiler.cmake builds the download name from CMAKE_HOST_SYSTEM_NAME only — on any Linux host it asks for llvm-mos-linux-main.tar.xz.
2. The llvm-mos release page ships llvm-mos-{linux,darwin,windows}-main, but there does not appear to be a separate Linux aarch64/arm64 asset for the Pi.

Easiest unblock: skip the bootstrap and point the SDK at an llvm-mos install you built yourself for aarch64. Build llvm-mos from source on the Pi (or cross-build it), then configure the SDK with:

cmake -B build \
  -DLLVM_MOS_BOOTSTRAP_COMPILER=OFF \
  -DLLVM_MOS=/path/to/your/llvm-mos-install \
  ...

find-mos-compiler.cmake checks LLVM_MOS first, so this should make the SDK use your existing mos-clang instead of the failing downloaded one.

[PacoPico8788]

Exactly right, I am now building out a new development environment on a W10/WSL laptop. Thank you!

…

On Wed, Jun 3, 2026 at 2:54 PM Aleksandr Kovalko ***@***.***> wrote: Adding a concrete workaround to the maintainer's diagnosis: this does look like an architecture mismatch. The bootstrap is downloading a prebuilt Linux mos-clang that is not runnable on the Pi's aarch64 userspace. The garbled bytes are likely the ELF header being parsed by the shell after the kernel fails to execute the binary. Two things make this happen: 1. cmake/bootstrap-compiler.cmake builds the download name from CMAKE_HOST_SYSTEM_NAME only — on any Linux host it asks for llvm-mos-linux-main.tar.xz. 2. The llvm-mos release page ships llvm-mos-{linux,darwin,windows}-main, but there does not appear to be a separate Linux aarch64/arm64 asset for the Pi. Easiest unblock: skip the bootstrap and point the SDK at an llvm-mos install you built yourself for aarch64. Build llvm-mos from source on the Pi (or cross-build it), then configure the SDK with: cmake -B build \ -DLLVM_MOS_BOOTSTRAP_COMPILER=OFF \ -DLLVM_MOS=/path/to/your/llvm-mos-install \ ... find-mos-compiler.cmake checks LLVM_MOS first, so this should make the SDK use your existing mos-clang instead of the failing downloaded one. — Reply to this email directly, view it on GitHub <#169?email_source=notifications&email_token=BG25OK7PTGCWJOXRAQW7YC346BX6RA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZRG4YDMNBYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17170648>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BG25OK4BTLWK74LGANZJ7OT46BX6RAVCNFSM6AAAAACZMLW3GSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTOMJXGA3DIOA> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BG25OKYZC6UE7V7QPWIP4IL46BX6RA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZRG4YDMNBYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/BG25OK7R4A2PHUMFTMYSV4T46BX6RA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZRG4YDMNBYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[gistrec]

Glad it helped! Quick note for your new setup: on W10/WSL (x86-64) the bootstrap will work out of the box, so you actually won't need the -DLLVM_MOS_BOOTSTRAP_COMPILER=OFF workaround there — that flag was only needed because the prebuilt binaries are x86-64 and don't run on the Pi's ARM64.

If this sorted it out, would you mind marking it as the Answer? Might save the next Pi/ARM64 user some digging. 🙂