This is an automated email from the ASF dual-hosted git repository. jimjag pushed a commit to branch msys2-dev-prototype in repository https://gitbox.apache.org/repos/asf/openoffice.git
commit fec32e0c2741cf7efba3edffb9dfaa558af61403 Author: Jim Jagielski <[email protected]> AuthorDate: Tue Aug 11 13:08:25 2026 -0400 Baseline the MSYS2 build at x86_64 and note the CCNUMVER gate hazard Windows on ARM is deferred, so key the platform on $(COM)$(OS)$(CPU) rather than $(COM)$(OS) to keep adding it a new OUTPATH instead of a refactor. --- MSYS2-WINDOWS-BUILD-FEASIBILITY.md | 60 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 57 insertions(+), 3 deletions(-) diff --git a/MSYS2-WINDOWS-BUILD-FEASIBILITY.md b/MSYS2-WINDOWS-BUILD-FEASIBILITY.md index 5bb9af9c7d..34c1c02532 100644 --- a/MSYS2-WINDOWS-BUILD-FEASIBILITY.md +++ b/MSYS2-WINDOWS-BUILD-FEASIBILITY.md @@ -1,8 +1,25 @@ # MSYS2 / clang as an alternative Windows build for Apache OpenOffice -Scope: x86_64 only, Windows 10+, **additive** — the existing MSVC path stays the +Scope: **x86_64 only**, Windows 10+, **additive** — the existing MSVC path stays the default and is not modified. Assessment against `trunk` as of 2026-08-11. +Explicitly out of scope, in both directions: + +- **32-bit Windows.** Not supported by this build mode. The existing `wntgcci` OUTPATH + and the `mingw_intel` bridge are 32-bit and are neither revived nor extended. +- **Windows on ARM (arm64).** Deferred. MSYS2 does ship a CLANGARM64 environment, so the + door is open, but nothing here is planned or estimated for it. x86_64 is the baseline + and the only target that Phase 1's go/no-go decision covers. + +Keep the architecture additive along the CPU axis as well as the compiler axis, so that +adding arm64 later is a new OUTPATH plus a new bridge rather than a refactor. Concretely: +key everything on `$(COM)$(OS)$(CPU)` as `GCCWNTX`, never on `$(COM)$(OS)` alone. If +Windows/arm64 is ever taken up it becomes `GCCWNTR` (or whatever CPU letter is chosen) +with its own `wntgccr.mk` and its own bridge — and that bridge is a **third** piece of +work, not a recompile: Windows/arm64 uses AAPCS64 with Microsoft's variations, so neither +the Win64/x86_64 bridge built here nor the existing `s5abi_macosx_aarch64` bridge would +drop in unchanged. + Goal, restated: *reduce and contain* the Microsoft dependency, not eliminate it. Use the Windows SDK where it is genuinely the cheapest correct answer; use mingw-w64 and MSYS2 packages everywhere else. Optimise for a build that is easy to set up, easy to @@ -107,7 +124,7 @@ are holding in reserve. If it is ever forced, the three items above are the bill | `__MINGW32__` conditionals | 100 files across the tree | | `solenv/bin/addsym-mingw.sh`, `_tg_def.mk` MinGW branches | Export/`.def` handling present | | ~20 external modules | Already have `WNT` + `COM=GCC` build recipes | -| `--with-system-*` | 38 options, none gated off on Windows | +| `--with-system-*` | 38 options; the 8 spot-checked are not gated off on Windows | All of it is 32-bit and none has had functional work in years — every recent commit touching these files is whitespace or mechanical. But the build system already @@ -230,6 +247,40 @@ one place and can be audited, version-pinned, and eventually shrunk further. **Risk: low-medium. Effort: moderate, touches many files.** +#### B5a — `COM=GCC` misroutes compiler-version detection + +A consequence of the `COM=GCC` decision that needs handling deliberately rather than by +accident. `configure.ac:2301-2303` derives the version for `COM=GCC` from +`${CC} -dumpfullversion -dumpversion`. Clang answers with *its own* version, so +`CCNUMVER` lands around `002000010000` for clang 20 and is then compared against gates +that were written to mean GCC versions. + +Most of the tree survives this by luck, because clang's major version sits above every +GCC gate: + +- `solenv/inc/rules.mk:97,109` and `openssl/makefile.mk:59` test + `COM==GCC && CCNUMVER >= 000300040000` / `>= 000400060000` → true, which is what we + want. +- `svx/Library_svxcore.mk:454` and `dbaccess/Library_dbui.mk:291` gate a GCC 4.9-specific + workaround on `4.9 <= CCNUMVER < 5.0` → false, also what we want. +- The `CCNUMVER <= 001399999999` gates in `extensions/source/ole/makefile.mk:75,99`, + `desktop/util/makefile.mk:233,249` and `embedserv/util/makefile.mk:67` are *MSVC* + version gates (13.x = VC7) that will now be evaluated against a clang version → false. + Probably the desired modern behaviour, but it is an accident: those branches were never + meant to be reached by a non-MSVC compiler at all. + +Decide this explicitly in Phase 0 — either add an MSYS2/clang branch to the version +decoding that sets `CCNUMVER` to something the `COM==GCC` gates interpret correctly, or +keep clang's real version and audit the gates once, documenting that GCC-version tests +are permanently "modern". Do not leave it implicit; a future clang major bump could flip +a gate nobody knew was live. + +Two adjacent pre-existing defects to be aware of while working here, neither introduced +by this project: `configure.ac:2306-2309` has an unreachable `elif` (both branches test +`CCNUMVER -ge 000300000001`), and `COM=CLANG` on non-Darwin already routes to +`COMID="gcc3"` at `configure.ac:2322-2325`, which is a second, separate path to the same +class of confusion. + ### B6 — Odds and ends - IDL: replace `midl.exe` with mingw-w64 `widl` in `extensions/source/activex/msidl` @@ -316,7 +367,10 @@ three `__declspec(uuid)` sites in `avmedia`; the ATL reference counts per module the fact that `shlxthandler`/`setup` use `MFC_INCLUDE` for resources only; the absence of a 64-bit GCC dispatch in `wnt.mk`; the `__MINGW32__`/`sal_Unicode` handling; the PSDK dependency in `external/mingwheaders`; the installer's required-tools list in -`control.pm:105`; the 38 `--with-system-*` options and their lack of Windows gating; the +`control.pm:105`; the existence of 38 `--with-system-*` options and the absence of Windows +gating in the 8 spot-checked (openssl, expat, libxml, curl, boost, hunspell, icu, nss — +the other 30 were not checked); the `COM=GCC` version-decoding path at +`configure.ac:2301` and the CCNUMVER gates named in B5a; the `COMEX` ≤ 12 ceiling on the MSVC path; and the staleness of the MinGW files in git history.
