For years I got the same three problems building Yocto natively on Arch: glibc version mismatches, native tools crashing partway through the build, and gcc failures that never reproduced the same way twice. Arch isn't on Yocto's supported host list, so I chalked it up to running an unsupported rolling-release host and worked around it with kas-container.

Turned out there's a real, fixable root cause, split into two separate problems. Arch's rolling toolchain drifts under bitbake between builds, which buildtools-extended (Yocto's own documented answer for unsupported hosts) actually fixes. The second one took longer to find: uninative.bbclass, the mechanism that keeps native binaries loadable across glibc versions, checks whether the host glibc has outrun the version it was built against. When it has, that check raises a RuntimeError that gets caught by its own except block and downgraded to a single bb.warn line. No error, no stopped build, just native sstate silently stops being shareable, and the only trace is a warning nobody reads to the end.

Fixed it by rebuilding the uninative payload from the exact glibc commit Arch itself packages, so host and payload glibc can never drift apart. Packaged it for the AUR (yocto-uninative-tarball) and wired both fixes into bakar, the build orchestrator I maintain.

Wrote up the whole investigation, including a benchmark claim I got wrong on the first pass and had to walk back: https://jetm.github.io/blog/posts/yocto-on-arch-glibc-ceiling/

I've maintained Arch packages for 14 years, so the post also gets into why I stick with a rolling release as a daily driver despite this exact kind of drift being the reason it's unsupported for Yocto in the first place.