---
id: "bug-1608"
status: "fixed"
status_updated: "2026-09-24"
status_note: ""
component: "build"
severity: "hang"
timestamp: "2026-08-20T15:57:00Z"
last_seen: "2026-09-19T09:00:00Z"
occurrences: 1
files: ["src/tools/go_build"]
tags: ["go", "go_build", "goproxy", "network", "hang", "sandbox", "meson", "build-time-versioning"]
related: ["bug-1597"]
legacy: true
---

# bug-1608: `xce-build.sh apiserver <profile> <dir>` (meson -> go_build custom_target) hung indefinitely…

## Description
`xce-build.sh apiserver <profile> <dir>` (meson -> go_build custom_target) hung indefinitely (8-10+ minutes, zero progress) building xcecli's Go dependencies; no error, no timeout, just stuck

## Environment
_Not recorded (migrated from buglog.json)._

## Reproduction
_Not recorded (migrated from buglog.json)._

## Root cause
go_build hardcodes `GOPROXY=https://goproxy.cn` plus a FRESH, per-invocation GOCACHE/GOPATH under meson's own $TMPDIR sandbox, bypassing the shell's already-populated default $GOPATH/pkg/mod module cache entirely. Confirmed via `ss -tnp` that the resulting `go` process had an ESTABLISHED (not refused/reset) TCP connection to 8.45.176.179:443 (=goproxy.cn, independently reachable fine via plain curl/`/dev/tcp` from the same shell) sitting in futex_do_wait with near-zero CPU time -- a genuinely stuck data path in this sandbox's networking for that specific fresh-cache+custom-GOPROXY combination, not mere slowness (never progressed no matter how long left running across 3 separate attempts). A plain `go list -m all` from an ordinary `nix develop` shell (no wrapper, default cache) resolved the identical apiserver module graph in under a second.

## Fix
Workaround only (go_build/Makefile NOT modified -- this is a sandbox-specific networking quirk, not a real defect in those files, and out of this task's scope to fix): for a standalone real apiserver/xcecli build in this sandbox, invoke `go build` directly against the default (already-populated) module cache with `GOPROXY=off` plus the same CGO_CFLAGS/CGO_LDFLAGS pkg-config derivation apiserver's own meson.build/test-backend already use (see bug-1597's documented fix for the exact derivation), instead of routing through xce-build.sh apiserver / go_build / make build-server. Diagnose a suspected hang via `ss -tnp` + `/proc/<pid>/wchan` before assuming it just needs more time.

## Verification
_Not recorded (migrated from buglog.json)._

## References
- Related: bug-1597