fix: force LLVM backend for x86_64 app executables to avoid .sframe linker crash

[mvanhorn]

Summary

The repo already contains the exact remedy: useLlvmWorkaround(target) in build/app.zig (returns true on x86_64) is applied to the mobile static lib, the test compile, and the model-contract exe - but NOT to the main app executable created in addAppArtifacts (b.addExecutable(.{ .name = app_options.name, .root_module = app_mod }), ~line 244). Add .use_llvm = useLlvmWorkaround(target) there so Debug app builds on x86_64 use LLVM+LLD and never hit the self-hosted linker's .sframe limitation; verify whether .use_lld must also be set explicitly on this Zig version (the upstream workaround sets both). Extend the useLlvmWorkaround doc comment to record this second justification (the .sframe R_X86_64_PC64 linker crash with GCC 15 crt1.o, issue #37) alongside the existing SysV f32 miscompile rationale.

Why this matters

On Linux x86_64 hosts with GCC 15+, Debug builds of Native SDK apps fail at link time with fatal linker error: unhandled relocation type R_X86_64_PC64 ... crt1.o:.sframe. GCC 15 emits .sframe sections into crt1.o, and Zig 0.15/0.16's self-hosted x86_64 linker (used for Debug builds) cannot process their R_X86_64_PC64 relocations - this is upstream Zig issue codeberg.org/ziglang/zig#31272, where the confirmed workaround is forcing the LLVM backend (.use_llvm = true), which links via LLD. Multiple users are affected (any Arch/Manjaro/CachyOS system with GCC 15), and a commenter on the issue linked the upstream fix/workaround.

See #37.

Testing

• Happy path: on x86_64-linux with GCC 15 crt1.o, zig build -Doptimize=Debug (and zig build run) for an app using addApp compiles and links successfully - the emitted compile uses the LLVM backend instead of the self-hosted x86_64 backend, so no R_X86_64_PC64 error. - Edge case: non-x86_64 targets (aarch64 macOS/Linux) are unaffected - useLlvmWorkaround returns null there, preserving current backend selection. - Edge case: Release builds are unchanged (they already default to LLVM); the flag only alters Debug-mode backend choice. - Regression guard: repo zig build test still passes; the existing file-contains checker step in root build.zig can gain a pattern asserting build/app.zig applies useLlvmWorkaround to the app exe so the workaround is not silently dropped.

Fixes #37

[vercel]

@mvanhorn is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[mvanhorn]

Addressed in b8899df; zig build passes locally on x86_64 and aarch64 hosts.

[sectore]

native dev in examples/native-shell still crashes. It has its own build.zig that calls b.addExecutable without use_llvm / use_lld. Do all examples with such build files need the same fix?

Tested on Ubuntu 24.04.4 LTS x86_64, Zig 0.16.0.

[mvanhorn]

Good catch — yes. The 11 examples that call b.addExecutable directly (everything except mobile-canvas and ui-inbox) need the same use_llvm/use_lld workaround; only mobile-canvas/ui-inbox don't build an executable directly. The wrinkle is that the examples import the SDK by source path rather than as a package, so they can't reach useLlvmWorkaround/useLldWorkaround from build/app.zig cleanly. Two options: (a) a relative @import("../../build/app.zig") in each example (simple, but can't honor -Dnative-sdk-path since @import needs a comptime literal), or (b) expose the two helpers from a tiny importable build/workaround.zig the examples import by the configurable path. I lean (b) so it stays correct under a custom SDK path. If you're good with (b), I'll roll it across the 11 examples and rebase onto main. Which do you prefer?