You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: build native libs via bash, not direct .sh execution (#75)
* fix: build native libs via bash, not direct .sh execution
exec-maven-plugin's <executable> pointed straight at
scripts/build-zstd.sh, relying on its shebang to make it directly
executable. That only works on macOS/Linux; Windows can't interpret
a shebang at all, so any native source build there failed outright:
Cannot run program ".../scripts/build-zstd.sh": CreateProcess
error=193, %1 is not a valid Win32 application
Never caught before because ci.yml only runs on ubuntu-latest, and
release-smoke.yml's Windows legs consume already-published artifacts
rather than building from source. The new benchmark-lto.yml workflow
is the first CI job to build natively on a Windows runner, and it
surfaced this on its first run (windows-x86_64 leg failed while
linux-x86_64/linux-aarch64/osx-aarch64 succeeded).
Fix: invoke `bash scripts/build-zstd.sh ...` explicitly instead of
executing the script directly. Applied uniformly to all six
native/*/pom.xml (not just the Windows two) - bash is on PATH on
macOS/Linux too, and GitHub's Windows runners ship Git Bash by
default (release-smoke.yml's `shell: bash` steps already rely on
this).
Verified locally: full clean rebuild + zstd/integration-tests suite
still passes on osx-aarch64, checkstyle clean.
* fix: handle unrecognized/Windows host OS in build-zstd.sh host detection
Second Windows-support bug in the same script, found while verifying
the exec-maven-plugin fix in this branch on an actual Windows runner:
once bash could finally launch the script, it immediately died at
scripts/build-zstd.sh: line 55: HOST_OS_NAME: unbound variable
Git Bash's `uname -s` reports "MINGW64_NT-..."/"MSYS_NT-..." (never
"Windows"), so the case statement matched neither Darwin nor Linux and
left HOST_OS_NAME unset - fatal under `set -u`. HOST_CLASSIFIER is
purely cosmetic (the "(cross from ...)" log hint; the actual build is
driven entirely by $ZIG_TARGET/$CLASSIFIER from argv, never by host
detection), but an unset variable still aborts the whole script under
set -euo pipefail.
Fix: add a Windows case (MINGW*/MSYS*/CYGWIN*) alongside Darwin/Linux,
plus a default `*)` arm on both case statements so no host can leave
the variable unset. This gives correct native-vs-cross detection on
Windows runners too, not just a crash-avoidance shim.
Verified locally: full clean osx-aarch64 rebuild still reports no
"(cross from ...)" hint (correctly detected as native), a
linux-x86_64 cross-build still correctly reports "(cross from
osx-aarch64)", zstd/integration-tests suite and checkstyle both pass.
0 commit comments