What breaks
build.sh is the documented local build entrypoint. Two lines are GNU coreutils–specific:
# build.sh:11-12
BUILD_DATE="$(date --utc)"
BUILD_ARCH="$(arch)"
On macOS (BSD userland):
date --utc → date: illegal option -- - (BSD date uses -u).arch exists but reports i386/arm64 instead of GNU x86_64/aarch64, leading to inconsistent BuildArch strings in version output across hosts.
On *BSD: same date issue.
On Windows: there is no bash shell to run build.sh at all — but go build itself works (release.yml uses go build directly with the same -ldflags, which is already portable).
Suggested fix
Replace with POSIX-portable equivalents:
BUILD_DATE="$(date -u +'%Y-%m-%dT%H:%M:%SZ')"
BUILD_ARCH="$(uname -m)"
Both work identically on GNU, BSD/macOS, and Alpine/busybox. As a bonus, the ISO-8601 timestamp matches what release.yml:97 already produces (date --utc --iso-8601=seconds), so version strings become consistent between local and CI builds.
Scope is small — this is purely about letting contributors on macOS run the project's own build script.
What breaks
build.shis the documented local build entrypoint. Two lines are GNU coreutils–specific:On macOS (BSD userland):
date --utc→date: illegal option -- -(BSDdateuses-u).archexists but reportsi386/arm64instead of GNUx86_64/aarch64, leading to inconsistentBuildArchstrings inversionoutput across hosts.On *BSD: same
dateissue.On Windows: there is no bash shell to run
build.shat all — butgo builditself works (release.yml usesgo builddirectly with the same-ldflags, which is already portable).Suggested fix
Replace with POSIX-portable equivalents:
Both work identically on GNU, BSD/macOS, and Alpine/busybox. As a bonus, the ISO-8601 timestamp matches what
release.yml:97already produces (date --utc --iso-8601=seconds), so version strings become consistent between local and CI builds.Scope is small — this is purely about letting contributors on macOS run the project's own build script.