feat(build): support crosscompile

[MeteorsLiu]

Design: https://github.com/xgo-dev/llar/wiki/Cross-compile-Design

[codecov]

Codecov Report

❌ Patch coverage is 86.62675% with 67 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 ⚠️

📢 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.

[MeteorsLiu]

TODO: change this signature to Use(Command) (Patch, error) to avoid panic, it requres #167