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
The following commit(s) were added to refs/heads/msys2-dev-prototype by this
push:
new df351b877b Re-baseline the MSYS2 assessment on measurement instead of
assumption
df351b877b is described below
commit df351b877b438faac545c44258cf63570e33f211
Author: Jim Jagielski <[email protected]>
AuthorDate: Tue Aug 11 14:00:42 2026 -0400
Re-baseline the MSYS2 assessment on measurement instead of assumption
ATL is unusable from a CLANG64 build: its headers dispatch on _M_X64 and
pull in MSVC's
own STL, neither of which exists under the GNU triple this project
requires. The de-ATL
port is therefore in scope, taking phase 3 to 8-14 weeks and the whole to
5-9
person-months. In exchange the ADO and DirectX headers turn out to come
from mingw-w64
after all, so external/mingwheaders has no successor and the Windows SDK
dependency
shrinks to the MSI tools and signtool -- no Visual Studio of any kind.
---
MSYS2-WINDOWS-BUILD-FEASIBILITY.md | 227 +++++++++++++++++++++++--------------
1 file changed, 142 insertions(+), 85 deletions(-)
diff --git a/MSYS2-WINDOWS-BUILD-FEASIBILITY.md
b/MSYS2-WINDOWS-BUILD-FEASIBILITY.md
index 3d55943278..8ccab62d91 100644
--- a/MSYS2-WINDOWS-BUILD-FEASIBILITY.md
+++ b/MSYS2-WINDOWS-BUILD-FEASIBILITY.md
@@ -27,9 +27,10 @@ run, and cheap to maintain.
## Verdict
-Feasible. With the Windows SDK allowed back in for the few things it uniquely
provides,
-the project reduces to roughly **3.5–6 person-months**, and all but one phase
is
-routine build-system work.
+Feasible, at roughly **5–9 person-months**. The Windows SDK still supplies the
MSI
+tools and the ADO headers, but **ATL cannot be consumed from a CLANG64 build**
—
+measured, see below — so the de-ATL port is in scope rather than avoided. All
but one
+phase is routine build-system work.
The single hard blocker remains: **there is no C++/UNO bridge for the Win64
calling
convention under the Itanium C++ ABI, and one must be written from scratch.**
Everything
@@ -39,8 +40,8 @@ from a standalone Windows SDK install.
The maintenance argument is the strongest one for doing this at all. The
current MSVC
path is pinned to `COMEX` ≤ 12 — VS2008 (`set_soenv.in:715-723`,
`configure.ac:2245`).
An MSYS2 build tracks a rolling, self-updating toolchain and depends on
Microsoft only
-through a small, explicitly-declared set of components — a current Windows SDK
and, for
-ATL, a Build Tools component — rather than on one pinned IDE.
+through a small, explicitly-declared set of components — a current Windows
SDK, and
+nothing else — rather than on one pinned IDE.
## Where each dependency comes from
@@ -51,7 +52,7 @@ ATL, a Build Tools component — rather than on one pinned IDE.
| C runtime | **UCRT** | In-box on Windows 10+; see the MSVCRT question below |
| Shell, perl, make, autotools, pkg-config | **MSYS2** | Replaces the Cygwin
dependency |
| Most bundled third-party libraries | **MSYS2 packages** via
`--with-system-*` | 38 such options already exist in `configure.ac` |
-| **ATL** | **VS Build Tools** — *not* the standalone SDK, see below |
mingw-w64 has none and no free ATL exists |
+| **ATL** | **nowhere — port it out** | Ships only with VS Build Tools, and
does not compile under CLANG64; see below |
| **MSI database tools** (`msidb`, `msitran`, `msiinfo`, `uuidgen`) |
**Windows SDK** | `msitools`/WiX are not worth the effort |
| **`signtool`** | **Windows SDK** | Only if producing signed builds |
| ADO headers (`adoint.h`, `adodef.h`, …) | **Windows SDK** | Keeps the ADO
database driver alive |
@@ -61,22 +62,49 @@ ATL, a Build Tools component — rather than on one pinned
IDE.
| JDK | **native Windows JDK** | MSYS2 ships none |
Net effect: **the Microsoft compiler is not used at all**, and the Microsoft
dependency
-reduces to four discrete, auditable items. That is the reduction that actually
matters —
-a current, versioned SDK and (for ATL) a Build Tools component, versus today's
dependency
-on one specific ancient Visual Studio.
-
-**Correction, pending the probe.** An earlier draft claimed all four items
come from a
-standalone Windows SDK with no Visual Studio involvement. That is probably
wrong for ATL:
-modern ATL ships as a Visual Studio / VS Build Tools component under
-`VC/Tools/MSVC/<ver>/atlmfc`, not under `Windows Kits`. AOO's own history
points the same
-way — `external/mingwheaders/makefile.mk:47` reads ATL out of
`$(PSDK_HOME)/include/atl`,
-i.e. the old Platform SDK, which today's standalone SDK is not a continuation
of for this
-purpose.
-
-If that holds, the honest statement is *"no Visual Studio IDE and no MSVC
compiler, but
-one Build Tools component for ATL"* — still a large reduction, but not the
clean claim.
-`msys2-probe.sh` searches both locations and settles it. The MSI tools and
`signtool` are
-genuinely Windows SDK, and are unaffected.
+reduces to a standalone Windows SDK — no Visual Studio of any kind. That is a
cleaner
+reduction than the previous draft claimed, but it is bought by porting ATL out
rather
+than by consuming it.
+
+### ATL: measured, and it does not work
+
+An earlier draft assumed ATL could be taken from a standalone Windows SDK. Two
things
+are now established on a real machine (`msys2-probe.sh`, Windows 10 19045,
clang 22.1.8,
+VS 2022 Professional present):
+
+**ATL is not in the standalone SDK.** It ships only as a Visual Studio / VS
Build Tools
+component under `VC/Tools/MSVC/<ver>/atlmfc`. AOO's own history said as much —
+`external/mingwheaders/makefile.mk:47` reads ATL out of
`$(PSDK_HOME)/include/atl`, the
+old Platform SDK, which today's standalone SDK does not continue.
+
+**Even with VS 2022 installed, ATL will not compile under CLANG64.** Three
include-set
+configurations were tried and each failed for a different, converging reason:
+
+| Include set | Outcome |
+|---|---|
+| `atlmfc/include`, `-fms-extensions -fms-compatibility` | mingw's own headers
break first: `vadefs.h` takes its `#error` branch, libc++ loses `aligned_alloc`
|
+| `atlmfc/include`, `-fms-extensions` | ATL's SAL annotations are undefined —
`_Ret_opt_`, `_Deref_pre_maybenull_` — because mingw's `sal.h` is a cut-down
copy |
+| MSVC `include` + SDK `ucrt`/`shared`/`um`/`winrt`, both flag sets |
`winnt.h:173` *"No Target Architecture"*, `<new>:44` *"Unsupported
architecture"*, `atldef.h:133` *"Unsupported target architecture."* |
+
+The third row is the decisive one. Those headers dispatch on `_M_X64` /
`_AMD64_`, which
+clang defines only when targeting `*-windows-msvc`; under the GNU triple this
build
+requires (`x86_64-w64-windows-gnu`) they are absent by design. And the include
chain
+shows `atldef.h` → `ucrt/new.h` → **MSVC's own `<new>` and `xtr1common`**: ATL
does not
+merely want the SDK, it wants MSVC's C++ standard library.
+
+Forcing `-D_AMD64_ -D_M_X64` would get past `winnt.h` and land squarely in
MSVC's STL,
+which cannot coexist with libc++ in one program. That last step is inference,
not
+measurement — but it is not worth spending time to confirm, because ATL also
ships a
+static library built for the MSVC C++ ABI, and this build targets the Itanium
ABI.
+Consuming ATL would require being clang-cl, which is a different project.
+
+**Conclusion: the de-ATL port of `winaccessibility`, `extensions/source/ole`
and
+`embedserv` is required, not optional.** That is the 6–10 week item this
revision hoped
+to delete, and it is what moves the estimate from ~3.5–6 to ~5–9 person-months.
+
+The MSI tools and `signtool` are genuinely Windows SDK and are unaffected. One
+consolation: with ATL gone, the SDK component list shrinks, and the "no Visual
Studio"
+claim becomes true without qualification.
## The UCRT vs MSVCRT question
@@ -96,30 +124,28 @@ Plus MSVC structured exception handling
(`__try`/`__except`) at 17 sites in `vcl
`sal/osl/w32`, `dtrans` and the MSVC bridges — again supported by clang on
mingw
targets, not by GCC.
-And now that we are deliberately consuming the SDK's ATL, a third reason
appears: ATL
-headers are MSVC C++ and need `-fms-extensions` / `-fms-compatibility` to
parse. Clang
-has those; GCC does not. This is precisely why the old
-`external/mingwheaders/mingw_atl_headers.patch` had to be 1654 lines — it was
patching
-ATL to survive *GCC*. Under clang that patch should shrink to a small shim or
vanish.
+Both are now measured rather than assumed: on CLANG64, `__try`/`__except`
compiles *and
+runs*, and `__uuidof` and `__declspec(uuid)` compile, all under
`-fms-extensions` alone.
-So clang is required three times over. And MSYS2's x86_64 clang environment is
+Note that `-fms-extensions` alone is the right setting. `-fms-compatibility` is
+actively harmful here — it breaks mingw's own `vadefs.h` and libc++ before any
project
+code is reached — and nothing in the tree needs it.
+
+So clang is required twice over. And MSYS2's x86_64 clang environment is
**CLANG64, which is UCRT-only** — there is no clang + MSVCRT environment
(MINGW64 is
GCC + MSVCRT, UCRT64 is GCC + UCRT). Choosing MSVCRT therefore means choosing
GCC,
which means:
1. Rewriting ~15 SEH sites;
2. Replacing every `__uuidof` / `__declspec(uuid)` with explicit `IID_*` GUID
- references across 14 production files;
-3. Abandoning SDK ATL and going back to a full de-ATL port of
`winaccessibility`,
- `extensions/source/ole` and `embedserv` — the 6–10 week item this revision
was
- meant to delete.
-
-Independently of all that, UCRT is simply the better target here. It is the
in-box CRT
-on Windows 10+ (no redistributable), and modern Windows SDK components
including ATL
-are themselves built against UCRT + vcruntime. Pairing SDK-provided ATL with an
-MSVCRT-based runtime would be a CRT mismatch — exactly the class of bug that is
-painful to diagnose. **Increasing our use of the Windows SDK argues for UCRT,
not
-against it.**
+ references across 14 production files.
+
+The de-ATL port is no longer on this list — it is required either way, so it
is a cost
+of the project rather than a cost of choosing GCC. That narrows the gap
between the two
+environments, but the two items above are still real and still unnecessary.
+
+Independently of all that, UCRT is simply the better target here: it is the
in-box CRT
+on Windows 10+, with no redistributable to ship.
MSVCRT is documented here as a rejected option with a known cost, not as a
fallback we
are holding in reserve. If it is ever forced, the three items above are the
bill.
@@ -178,30 +204,36 @@ done and shipped.
**Risk: high. This is the go/no-go gate; prototype it before committing to the
rest.**
-### B2 — ATL from the Windows SDK
+### B2 — de-ATL port (measured as required, not optional)
Four production modules need ATL: `winaccessibility/source/UAccCOM`
(IAccessible2,
i.e. NVDA/JAWS support), `extensions/source/ole` (UNO ↔ OLE Automation),
`embedserv` (OLE embedding), `extensions/source/activex` (ActiveX control).
-With the SDK allowed, these are **kept, not ported**. Work reduces to:
+Since ATL cannot be compiled under CLANG64 at all (see the measurement above),
each of
+these must be reworked to use plain COM instead:
-- A lean replacement for `external/mingwheaders` that adds the SDK's
`include/atl` to
- the include path and applies whatever residual shims clang still needs.
Expect this
- to be far smaller than the old 1654-line GCC-targeted patch; possibly empty.
-- Compiling those four modules with `-fms-extensions -fms-compatibility`.
-- Confirming ATL's static lib links cleanly against the UCRT-based mingw
runtime.
+- `CComPtr` / `CComQIPtr` → the tree's own
`sal/inc/systools/win32/comptr.hxx`, which
+ already exists and already works under clang.
+- `CComBSTR` / `CComVariant` → direct `SysAllocString` / `VariantInit`
handling.
+- `CComObjectRootEx`, `CComCoClass`, the `BEGIN_COM_MAP` interface maps, and
+ `CComModule` registration → hand-written `IUnknown` implementations and
explicit
+ class-factory registration. This is the bulk of the work.
+
+`extensions/source/activex` (IE-era ActiveX control) is the most ATL-saturated
and the
+least valuable; excluding it from this configuration is the obvious first cut,
since the
+MSVC build still produces it.
`shell/source/win32/shlxthandler` and `desktop/win32/source/setup` reference
`MFC_INCLUDE` only for **resource compilation** — zero MFC code usage.
Include-path
fixes, not ports.
-`extensions/source/activex` (IE-era ActiveX control) remains a reasonable
candidate to
-exclude from this configuration if it fights back, since the MSVC build still
produces
-it.
+Prior art exists: LibreOffice removed ATL from these same modules to support
mingw, and
+`external/mingwheaders/mingw_atl_headers.patch` (1654 lines) shows how far the
tree was
+once willing to go in the other direction — worth reading as a map of which
ATL surface
+is actually used, not as something to revive.
-**Risk: medium — hinges on how cleanly clang parses current SDK ATL headers.
Verify
-early; it is cheap to test and it re-opens the 6–10 week de-ATL port if it
fails.**
+**Risk: medium. Effort: 6–10 weeks. No longer contingent — this is the
measured path.**
### B3 — cli_ure / .NET bindings (unavoidable, and acceptable)
@@ -311,10 +343,11 @@ class of confusion.
"/manifestdependency:...")` for the common-controls v6 manifest. Clang-mingw
ignores
it; embed the manifest as an `RT_MANIFEST` resource instead, or themed
controls
silently regress.
-- `connectivity/source/drivers/ado`: `comdef.h`/`_com_ptr_t` should come from
- mingw-w64; the ADO headers themselves come from the SDK. Verify.
-- `canvas/source/directx`, `avmedia/source/win`: use mingw-w64's d3d9/dshow
headers;
- the legacy DirectX SDK dependency should be droppable. Verify.
+- `connectivity/source/drivers/ado`: **verified** — mingw-w64 supplies
`comdef.h`
+ (`_com_ptr_t`) *and* `adoint.h`, so the ADO driver needs no SDK headers at
all. The
+ SDK row for ADO headers in the dependency table above is obsolete.
+- `canvas/source/directx`, `avmedia/source/win`: **verified** — mingw-w64's
`d3d9.h`
+ and `strmif.h` both compile; the legacy DirectX SDK dependency is droppable.
- Resources: `windres` or `llvm-rc` for `.rc`.
- STLport already defaults off, so libc++ is not fighting a bundled STL. It
*is* a
divergence from the proven libstdc++ Linux build — expect some strictness
fallout in
@@ -327,8 +360,8 @@ Deliverables that should be part of the work, not
afterthoughts:
1. A `pacman -S` one-liner package list, checked into the tree.
2. A bootstrap/build script following the pattern of the existing
`build_aoo64bit_on_macosarm.sh`, so a new machine is one script away from a
build.
-3. A documented minimal Windows SDK component selection (ATL + MSI tools +
signtool),
- with the standalone-installer link — no Visual Studio.
+3. A documented minimal Windows SDK component selection (MSI tools +
signtool), with
+ the standalone-installer link — no Visual Studio, no Build Tools.
4. A single canonical `./configure` invocation for the MSYS2 build, favouring
`--with-system-*` by default.
@@ -347,8 +380,9 @@ triple, so the MSVC build is untouched by construction:
4. New bridge directory `bridges/source/cpp_uno/mingw_x86-64/`.
5. New `solenv/gbuild/platform/winclang.mk` for gbuild-converted modules —
branch from
`winmingw.mk` rather than editing it, since that file is 32-bit-shaped.
-6. Replace `external/mingwheaders` with a minimal SDK-ATL include shim rather
than
- reviving its PSDK header-copying.
+6. Retire `external/mingwheaders` outright. Its PSDK header-copying has no
successor:
+ the ADO and DirectX headers it existed to supply now come from mingw-w64,
and its
+ ATL patching is superseded by the de-ATL port.
## Phasing and effort
@@ -357,13 +391,15 @@ triple, so the MSVC build is untouched by construction:
| 0 | Host env, `msys*` detection in configure, `set_soenv.in`, `wntgccx.mk`,
dmake bootstrap, SDK entry point | 2–3 weeks |
| 1 | **Win64 GNU-ABI UNO bridge** + sal/cppu/cppuhelper building and
`bridgetest` passing | 6–10 weeks |
| 2 | Externals via `--with-system-*`; packaging file lists for MSYS2 + libc++
runtime DLLs | 2–4 weeks |
-| 3 | Windows integration modules against SDK ATL; `widl` migration; manifest
fix | 2–4 weeks |
+| 3 | de-ATL port of the Windows integration modules; `widl` migration;
manifest fix | 8–14 weeks |
| 4 | Installer using SDK MSI tools; signing | 2–3 weeks |
-**Roughly 3.5–6 person-months**, down from 6–12 in the SDK-free version. Phase
1
-dominates and is the go/no-go gate. Phase 3's estimate assumes SDK ATL
compiles under
-clang with minimal shimming — cheap to test in a day, and worth testing during
Phase 0
-because failure reinstates a 6–10 week de-ATL port.
+**Roughly 5–9 person-months.** Phases 1 and 3 dominate; phase 1 remains the
go/no-go
+gate and is the only one that can invalidate the whole approach.
+
+Phase 3 was 2–4 weeks while SDK ATL looked viable. The probe settled that it
is not,
+which adds the 6–10 week de-ATL port. This is now a measurement, not an
assumption —
+the estimate should not move again on this point.
## Capability delta versus the MSVC build
@@ -371,14 +407,19 @@ Permanently absent:
- .NET/CLI UNO bindings (`cli_ure`, `climaker`) — no C++/CLI in clang.
Mitigated by
the MSVC build remaining the default.
-Retained by using SDK ATL (these were the at-risk items in the SDK-free plan):
+Retained, but only via the de-ATL port in B2 — these are the items that carry
the
+schedule risk, since each needs its ATL usage rewritten before it works at all:
- IAccessible2 accessibility bridge — screen-reader support.
- UNO ↔ OLE Automation bridge.
- OLE embedding server.
-- ActiveX control, unless deliberately excluded.
-Undetermined pending verification:
-- ADO database driver, DirectX canvas backend, DirectShow media backend.
+Likely dropped from this configuration:
+- ActiveX control (`extensions/source/activex`) — the most ATL-saturated and
least
+ valuable of the four; still produced by the MSVC build.
+
+Verified present, no longer at risk:
+- ADO database driver (`comdef.h`, `adoint.h`), DirectX canvas backend
(`d3d9.h`),
+ DirectShow media backend (`strmif.h`) — all compile against mingw-w64
headers.
## What I verified versus what I asserted
@@ -394,22 +435,38 @@ CCNUMVER gates named in B5a; the
`COMEX` ≤ 12 ceiling on the MSVC path; and the staleness of the MinGW files in
git
history.
-Asserted from knowledge of the toolchains, **not** verified against a live
MSYS2 or
-Windows SDK install:
-
-- That MSYS2 CLANG64 targets `x86_64-w64-windows-gnu` with the Itanium C++
ABI, libc++
- and compiler-rt, and that no clang + MSVCRT environment exists for x86_64.
-- That clang supports `__try`/`__except`, `__uuidof` and `__declspec(uuid)` on
mingw
- targets and GCC does not.
-- That clang's `-fms-extensions`/`-fms-compatibility` are sufficient to parse
current
- Windows SDK ATL headers — **the highest-value thing to test first**, since
it decides
- Phase 3's size.
-- **Where ATL actually comes from.** An earlier draft asserted the standalone
Windows SDK
- carries it; on reflection that is probably wrong (modern ATL is a VS Build
Tools
- component). Neither the old claim nor the correction has been verified on a
real
- machine — `msys2-probe.sh` section 6 searches both locations.
-- That mingw-w64 provides `comdef.h`, d3d9 and dshow headers, and that `widl`
is an
- adequate `midl` replacement.
-- That MSYS2 packages exist and are usable for the `--with-system-*` set named
above.
+Measured by `msys2-probe.sh` on Windows 10 19045 (x86_64), MSYS2 CLANG64,
clang 22.1.8,
+Windows SDK 10.0.19041.0, VS 2022 Professional present:
+
+- CLANG64 targets `x86_64-w64-windows-gnu` with libc++ over UCRT, as assumed.
+- `__try`/`__except` compiles **and runs**; `__uuidof` and `__declspec(uuid)`
compile —
+ all under `-fms-extensions` alone. `-fms-compatibility` is not needed and is
harmful.
+- ATL: not in the standalone SDK, and does not compile under CLANG64 from the
VS 2022
+ copy either, in any of three include-set configurations. Phase 3 is
re-baselined at
+ 8–14 weeks on this basis. See the ATL section above.
+- mingw-w64 supplies `windows.h`, `unknwn.h`, `shlobj.h`, `uxtheme.h`,
`comdef.h`,
+ `d3d9.h`, `strmif.h` and `adoint.h` — the full set this project needs,
including the
+ ADO headers previously expected to require the SDK.
+- A typed C++ exception thrown in one DLL is caught as its **exact derived
type** in
+ another — an encouraging early signal for B1, though it exercises neither
RTTI
+ synthesis nor Win64 marshalling.
+- All 24 candidate `--with-system-*` libraries exist in the clang64 repository.
+- MSI tools (`msidb`, `msitran`, `msiinfo`) and `signtool` are present in the
SDK but
+ off PATH; `makecab` and `expand` are in-box. A native JDK is found off PATH
and passed
+ via `--with-jdk-home`.
+
+Still asserted, **not** verified:
+
+- That no clang + MSVCRT environment exists for x86_64 (CLANG64 being
UCRT-only).
+- That GCC-mingw implements none of `__try`, `__uuidof`, `__declspec(uuid)` —
the
+ argument for clang rests on this, and only the clang half was measured.
+- That `widl` is an adequate `midl` replacement. Header availability was
tested;
+ compiling AOO's actual `.idl` files was not.
+- That the named MSYS2 packages are *usable*, not merely present — none was
built
+ against.
+- That mixing MSVC's STL into a libc++ build is unworkable, and that ATL's
MSVC-ABI
+ static library cannot link into a GNU-ABI binary. Both are the reasoning
behind
+ stopping the ATL investigation rather than measurements; the header-level
failure is
+ independently sufficient.
No build was attempted; there is no Windows or MSYS2 host in this environment.
