Drop BUILD_JOBS to 1 to bypass BuildKit -j>1 parallel-make race

Even with HOSTCC=gcc HOSTCXX=g++ passed on the make command line (which
correctly overrides Make.inc's HOSTCC=$(CC)+-m64 logic in the libwhich
sub-make), CI still fails with 'gcc: error: x86_64: linker input file
not found' in another autoconf configure script running in parallel.
Locally, '-j4 install-libwhich' succeeds with the override but '-j4
julia-deps' under docker build still hits a stray-token issue in some
other dep's configure. The pattern only reproduces under BuildKit's
docker build with parallel make.

Use -j1 in CI for now — reliable, ~25 min for deps phase instead of
~12 min, and Julia's sysimg/precompile phase isn't bottlenecked on -j.
Re-introduce parallelism once the actual stray-token source is
identified upstream (Julia/Make.inc, libwhich.mk, or BuildKit).

Also docs: README explicitly notes the Windows variant has NO Julia,
to avoid the 'why did it succeed in 26 seconds' question (it succeeds
because the windows job is a thin wrapper over dockcross with cbindgen
added; subsequent runs hit BuildKit's GHA layer cache).

Signed-off-by: Joris Gillis <joris@yacoda.com>

Author: jgillis

.github/workflows/build-image.yml

@@ -90,7 +90,14 @@ jobs:
             BASE_IMAGE=${{ matrix.base_image }}
             TARGET_ARCH=${{ matrix.target_arch }}
             JULIA_VERSION=${{ steps.tags.outputs.julia_version }}
-            BUILD_JOBS=4
+            # BuildKit's docker build with -j>1 hits a parallel-make race in
+            # Julia's deps phase where a stray $(ARCH) token leaks into a
+            # gcc invocation (`gcc: error: x86_64: linker input file not
+            # found` from a configure script + libwhich.o builtin recipe).
+            # Reproduces locally with docker build; does NOT reproduce with
+            # docker run or with -j1. Trade build time for reliability for
+            # now. ~2x slower than -j4 in deps phase (~25 min vs ~12).
+            BUILD_JOBS=1
           push: ${{ github.event.inputs.push != 'false' }}
           tags: |
             ${{ steps.tags.outputs.tag_arch }}

README.md

@@ -11,6 +11,8 @@ plus a multi-arch `ghcr.io/casadi/polyglot:manylinux_2_28` manifest.
 
 Layered on `ghcr.io/jgillis/manylinux_2_28-{x64,aarch64}:production`:
 
+### Linux variant (`Dockerfile.linux`)
+
 | Tool          | Where it comes from                                 |
 |---------------|-----------------------------------------------------|
 | GCC 14 toolset | Base manylinux_2_28 image (gcc-toolset-14)         |
@@ -19,6 +21,15 @@ Layered on `ghcr.io/jgillis/manylinux_2_28-{x64,aarch64}:production`:
 | cbindgen 0.28 | `cargo install` (per jgillis/dockcross 6a0fa8d)     |
 | Julia (multi-target, no libunwind) | Built from source in this image |
 
+### Windows variant (`Dockerfile.windows`) — **no Julia**
+
+| Tool          | Where it comes from                                 |
+|---------------|-----------------------------------------------------|
+| mingw-w64 cross GCC 11 | Base `dockcross/windows-shared-x64-posix`  |
+| Rust stable + cargo | Base image                                   |
+| cbindgen 0.28 | `cargo install`                                     |
+| Julia         | **Not included.** Cross-compiling Julia from Linux to mingw32 (`XC_HOST=x86_64-w64-mingw32`) is non-trivial and not attempted yet. Consumers that need Windows + Julia should bake the official Julia Windows .zip into a downstream image. |
+
 The Julia build uses our `Make.user`:
 
 ```make