feat(build): support crosscompile

[MeteorsLiu]

This PR adds cross-compilation support to the LLAR build pipeline for C libraries.

The implementation includes:

• Add target-aware command rewriting and LLVM toolchain selection for Linux and Darwin targets.
• Support default, custom, and Formula-provided sysroots while keeping sysroot builds on the bootstrap target.
• Propagate target compiler and pkg-config environments through execbroker, CMake, and Autotools builds.
• Return actionable errors from pkgconfig.Use, preserve missing optional pkg-config directories, and handle the result in Go and Formula callers.
• Cover target preparation, sysroot selection, cache behavior, and cross-platform artifacts with focused and end-to-end tests.

The design is documented at https://github.com/xgo-dev/llar/wiki/Cross-compile-Design. This keeps target behavior centralized while allowing existing Formulas to use the same build-system APIs.

[codecov]

Codecov Report

❌ Patch coverage is 86.22754% with 69 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/crosscompile/c/target.go	83.66%	25 Missing and 8 partials ⚠️
internal/crosscompile/crosscompile.go	84.61%	9 Missing and 9 partials ⚠️
internal/crosscompile/c/llvm/toolchain.go	90.00%	3 Missing and 5 partials ⚠️
cmd/llar/internal/make.go	76.00%	4 Missing and 2 partials ⚠️
internal/build/http/http.go	88.88%	1 Missing and 1 partial ⚠️
x/cmake/cmake.go	80.00%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!

[MeteorsLiu]

/review

[fennoai]

Review: cross-compile target support

Solid, well-tested feature (strong error-path/darwin/linux/gnu-musl coverage, defensive slice copies in the toolchain accessors). One issue is a potential process deadlock and should be addressed before merge; the rest are correctness/robustness and maintainability notes. Non-blocking review.

Highlights

• Critical: the new target middleware panics for recoverable errors, and the execbroker holds a non-deferred RLock across the middleware call — a panic leaks the read lock and deadlocks the process. See inline comments on internal/execbroker/execbroker.go, internal/crosscompile/c/target.go, and internal/crosscompile/crosscompile.go.
• Important: a partial --os/--arch matrix is misclassified as cross-compile (cmd/llar/internal/make.go).

Minor / maintainability (not inlined)

• internal/crosscompile/crosscompile.go (customTarget doc comment, ~lines 33-35): "customTarget uses the bootstrap toolchain to build libc itself" is inaccurate — Load returns bootstrapTarget when root.Path == cSysroot.Path, so customTarget actually builds a consumer against a Formula-supplied libc, not libc itself. Suggest rewording.
• internal/crosscompile/c/toolchain.go (lines 27-33): exported accessors CC()/CXX()/Linker()/Archiver()/Ranlib()/NM()/Strip() lack doc comments while every other exported symbol in the package has one; revive/golint will flag this.
• internal/crosscompile/c/target.go (autotoolsPatch): the --host detection re-reads and scans the configure script on every autotools command. The result is deterministic per target and could be cached alongside tempDir/toolchainFile. Low impact.
• Latent concurrency: both Use methods lazily initialize shared fields (toolchainFile/tempDir, configured) without synchronization. Safe today because builds run sequentially, but build.go carries a // TODO(MeteorsLiu): Parallel build note — worth a comment documenting the assumption or a sync.Once guard.

Findings without inline locations

• internal/execbroker/execbroker.go:149: scopeMu.RUnlock() here is not deferred, and scope.Middleware(req) (line 146) is called inside the locked region. The new C-target middleware can panic (see crosscompile.go and c/target.go Use methods), and a panic unwinds past this line, leaking the read lock permanently and deadlocking the next scopeMu.Lock(). Recommend defer scopeMu.RUnlock() (or a recover) so the lock is always released, in addition to fixing the middleware to not panic.

[luoliwoshang]

这里之前在LLGo构建发布时碰到一些交叉构建的问题：https://github.com/xgo-dev/llgo/blob/main/.github/actions/setup-goreleaser/action.yml。
这里会提前准备一整个linux环境，包括所有/usr/lib,/usr/include，用来构建LLGo,其实是因为会依赖一些 build-essential zlib1g-dev工具，在我们这里，有必要准备一个类似的方案么，即扣出一个稍微完整的环境进行构建

[luoliwoshang]

经过我们上次讨论，其实这部分应该会是llar交叉构建时的逻辑