new(winehq.org): headless wine for Windows-binary CI testing#12986
new(winehq.org): headless wine for Windows-binary CI testing#12986tannevaled wants to merge 8 commits into
Conversation
Minimal headless wine build — no X11, no OpenGL, no audio, 64-bit only, no wine tests. Aimed at the use case described in pkgxdev#12985 and the brewkit#346 RFC: run cross-compiled .exe files inside brewkit's Linux test sandbox to validate native-Windows pantry recipes. What it provides: - bin/wine, bin/wine64 (the runtime) - bin/winepath (path-translation helper) - bin/wineserver (the wine background service) - bin/winecfg (mostly stub-useful, included for completeness) What it does NOT support: - GUI apps (no X11) - 3D / Vulkan / OpenGL - Audio (ALSA, Pulse, OSS all disabled) - Multimedia (SDL, gstreamer disabled) - Peripherals (USB, CUPS, gphoto, V4L2, SANE all disabled) - 32-bit Win binaries (--enable-archs=x86_64 only) - Wine's own test suite (--disable-tests) Pilot platform: linux/x86-64 only. linux/aarch64 + darwin/* are follow-ups (wine-side complications: aarch64 needs qemu-user or hangover for x86-64 Win binaries; darwin needs the macOS-32-bit dance). Test step: `wine64 --version` returns "wine-X.Y" — proves the binary loads + can run a basic console command. Recipes that depend on wine (starting with pkgxdev#12984's llvm-mingw test step) get the full runtime check for free. Refs: pkgxdev#12985 (this issue), pkgxdev/brewkit#346 (RFC).
… .../X.x/, broke URL template
Brewkit's github: codepath silently ignores match:, so my previous regex didn't filter anything — pantry picked wine-11.9 (dev release) which lives in dl.winehq.org/source/11.x/, not /11.0/, so the URL template 404'd. Switch to url: mode (same shape as gnu.org/glibc): url: https://dl.winehq.org/wine/source/ match: /\d{2,}\.0\// # only stable major-version directories strip: /\// Picks the latest stable (currently wine-11.0). Excludes 11.x/ dev release dirs because match looks for an exact \d.0/ pattern.
CI surface: `configure: error: x86_64 PE cross-compiler not found` because --enable-archs=x86_64 implicitly requires a mingw cross- compiler on PATH (to build wine's Windows-side DLLs from source). For our headless-CI use case we don't need built-from-source win DLLs — wine's builtin ones (no mingw, fallback path) are sufficient to load + execute simple PE binaries. Bonus: avoids the build-dep cycle with pkgxdev#12984 (llvm-mingw) once that recipe lands — wine would otherwise build- depend on the cross-compiler whose recipe build-depends on wine for its own runtime testing.
|
Round 3 finding: wine is also blocked on #12968.
That makes sense: wine MUST build its own Windows-side DLLs (kernel32, ntdll, …) for the requested target arch, because those DLLs interpose Windows API calls into Linux syscalls. There's no "ship without Windows-side DLLs" path. So wine builds need a mingw cross-compiler. Adding So this PR's full unblock chain is #12968 → #12984 → this. For now: leaving the recipe with the current (Side note: |
note that this should be updated once pkgxdev#12986 is merged.
configure aborted with `x86_64 PE cross-compiler not found`: modern Wine
builds its built-in DLLs as real PE binaries and has no ELF-builtin
fallback, so `--without-mingw` doesn't avoid the requirement — it still
needs a PE cross-compiler. Now that llvm.org/mingw-w64 is in main, add it
as a build dep (it provides x86_64-w64-mingw32-{gcc,clang}) and switch to
`--with-mingw`. No build-dep cycle: the mingw recipe only uses Wine in its
test step.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ished Validated locally on Debian: `./configure --with-mingw --enable-archs=x86_64` (and aarch64) detects the mingw PE cross-compiler and succeeds. The earlier CI red likely built mingw-w64 from source inline (bottle not yet published); re-running against the published bottle. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Hey @jhheider — dug into the The recipe is correct. With
Ruled out as the cause of the CI
So the (Recipe fix is pushed; the rest of the CI is green.) Thanks! |
|
Best way to get the conf log is to cat it in the build script. |
include debugging cat of config.log
|
looks like glibc version needs; this is a good opportunity to test the libc wrapper tech. |
Phase-0 pilot recipe for the Windows-port architecture sketched at pkgxdev/brewkit#346. Cross-compiles jq from a Linux runner (via pkgxdev#12984's llvm.org/mingw-w64 toolchain), produces bin/jq.exe, runs it through wine in the test step (via pkgxdev#12986's headless winehq.org recipe). Build side: - Detect platform via {{hw.platform}}; on windows/* set --host triple + CC=<triple>-clang - --disable-onigjq because oniguruma doesn't have a Windows bottle yet (gap tracked in pkgxdev#346); regex jq features disabled on Windows - --disable-shared so the .exe is self-contained (no .dll deps to bundle for the pilot) Test side: - On linux/darwin: same as before — `jq .devs[1].github` returns "jhheider" from the existing test.json fixture - On windows/*: run jq.exe through wine64 with the same fixture - If wine isn't available: fall back to a PE magic-byte check on the produced .exe (best-effort, lets the test pass when wine isn't yet in pantry, auto-upgrades to a real check when it is) Known limitations of this pilot: - Uses jq 1.x semantics; doesn't exercise oniguruma-dependent regex filters on Windows - provides: bin/jq — pantry's audit may complain about bin/jq.exe on Windows. If so we need a brewkit hook to accept platform- appropriate suffixes (e.g. bin/jq → bin/jq.exe on windows/*) - Build dep on llvm.org/mingw-w64 pulled unconditionally; harmless on non-Windows but ideally conditional. Worth fixing in brewkit once pkgxdev#346 settles on conditional-deps semantics. Refs: pkgxdev/brewkit#346, pkgxdev#12984, pkgxdev#12986.
2 participants
Closes #12985.
What
Adds a
winehq.orgrecipe — a minimal headless build of Wine sufficient to run console-only Windows binaries on a Linux host. Pilot scope: linux/x86-64 only.Why
Unblocks #12984 (
llvm.org/mingw-w64) — that recipe's test step is already wired with a soft-dep onwinehq.org, so once this lands the cross-compile pilot upgrades from "PE magic-byte check" to "actually run the .exe and assert stdout". More broadly: any future Windows-targeting pantry recipe gets real runtime tests in the existing Linux CI infra (no GitHub Windows runners needed).Architecture context: pkgxdev/brewkit#346 RFC.
Build configuration
Stripped down to the minimum needed for CLI tool execution:
--enable-archs=x86_64--disable-tests--without-x--without-opengl --without-osmesa --without-vulkan--without-alsa --without-pulse --without-oss--without-sdl --without-gstreamer--without-cups --without-gphoto --without-usb --without-v4l2 --without-sane --without-udev --without-pcap--without-fontconfig --without-krb5 --without-capi --without-cmsBuild deps from pantry:
gnu.org/bison,github.com/westes/flex,perl.org,gnu.org/gettext,freetype.org,gnutls.org,zlib.net, plus the toolchain (gnu.org/{make,gcc,binutils}).Test
wine64 --version # expects "wine-X.Y"That's all. Anything more substantive belongs in consumer recipes (e.g.,
llvm-mingwruns hello.exe through wine).Limitations / future work
--with-mingwproduces wine with better Windows compat for the win-side DLLs, but requires a Linux-hosted mingw toolchain present at wine build time (which we now have via new(llvm.org/mingw-w64): LLVM-based mingw-w64 cross-compiler (Windows-target toolchain) #12984). Possible follow-up to unlock harder-to-emulate APIs.Test plan
wine64 --versionreturnswine-11.0(or whatever stable is at build time)hello.exethrough this wine when both PRs are mergedRefs: #12985 (this issue), pkgxdev/brewkit#346 (Windows port RFC), pkgxdev/pkgx#607 (platform megaticket).