ci(probe): drop windows_amd64_mingw exclusion — see if MEOS vcpkg port builds under MinGW#171
Open
estebanzimanyi wants to merge 6 commits into
Open
ci(probe): drop windows_amd64_mingw exclusion — see if MEOS vcpkg port builds under MinGW#171estebanzimanyi wants to merge 6 commits into
estebanzimanyi wants to merge 6 commits into
Conversation
The MEOS `*_as_hexwkb` family produces odd-length hex output on macOS arm64, which the DuckDB test framework's hex decoder rejects. The bug is real and MEOS-side; until it's fixed, every MobilityDuck PR that includes hex-WKB-touching SQL tests sees a red osx_arm64 build, which gates merges on a bug none of the PRs own. Consolidation: - MainDistributionPipeline.yml: add `osx_arm64` to `exclude_archs` (both build and deploy jobs, kept in sync). Every PR currently blocked solely by the inherited hex-WKB red goes fully green without changing its content. - HexWKBDiagnostic.yml (new): builds **only** osx_arm64 with the hex-WKB diagnostic instrumentation (PR MobilityDB#162 = `diag/hex-wkb-*`). Triggers: push to `diag/hex-wkb-*` branches, daily 06:00 UTC cron, manual dispatch. Keeps the bug observable while it isn't gating production PRs. Trade-off accepted: osx_arm64 stops gating unrelated arm64 regressions until the hex-WKB bug is fixed. When the diagnostic surfaces clean output for two consecutive cron cycles, drop `osx_arm64` from the production exclusion list and retire HexWKBDiagnostic.yml — that's a 2-line revert of this PR.
…t builds under MinGW
MinGW provides <dirent.h> and supports GCC __attribute__ syntax, so the
two source-level blockers that prevent an MSVC-native MEOS build are
absent on the MinGW path. This probe lets CI tell us whether the MEOS
vcpkg port actually builds end-to-end under MinGW.
Two possible outcomes:
- MinGW row goes green → MobilityDuck gets free Windows binaries
from the existing CI matrix, no further work needed for the
MinGW target.
- MinGW row fails → the failure log identifies the precise next
blocker, which is the data needed to scope the follow-up.
Stacks on MobilityDB#170 (osx_arm64 exclusion). Independent of MobilityDB #1104
(pg_attribute_unused macro fix) and MobilityDB #959 (MSYS2/UCRT64
Windows MEOS bootstrap) — those address the source-level blockers
for the MSVC-native target, which remains excluded here.
estebanzimanyi
force-pushed
the
ci/probe-mingw-build
branch
from
c9a7e14 to
cf25d64
Compare
estebanzimanyi
added a commit
to estebanzimanyi/MobilityDuck
that referenced
this pull request
May 21, 2026
…uilds against musl-libc
The MEOS-port-side glibc-isms are the suspected blockers — printf
format flag handling in postgres/utils/formatting.c, fpos_t opacity,
__GLIBC__-guarded paths, getline availability — but the precise
failure log is the data needed to scope the per-blocker fix.
Two possible outcomes:
- musl row goes green → free linux musl binaries; the exclusion
stays dropped.
- musl row fails → the failure log identifies the precise next
blocker. This PR is amended to put linux_amd64_musl back with a
comment naming the specific failure.
Stacks on MobilityDB#171 (MinGW probe), which stacks on MobilityDB#170 (osx_arm64). The
three probes are independent: one outcome doesn't affect the others.
… PR MobilityDB#161) Cherry-picked from open PR MobilityDB#161 so this PR's CI compiles against the vcpkg-installed MEOS, which exposes 'meosType' (pre-consolidation) not 'MeosType'. When MobilityDB#161 reaches main, this commit collapses to a no-op on rebase.
…MobilityDB#136) Cherry-picked from open PR MobilityDB#136 so this PR's amd64 Linux test phase goes green before MobilityDB#136 lands. When MobilityDB#136 reaches main, this rebase collapses to a no-op.
…en PR MobilityDB#140) Cherry-picked from open PR MobilityDB#140 so this PR's osx_amd64 / osx_arm64 / wasm builds compile. On macOS LP64 and Wasm/emscripten, int64 (long) and int64_t (long long) are the same width but distinct types; clang rejects passing bigint_to_set where Set *(*)(int64_t) is expected. The cast is a no-op on Linux. When MobilityDB#140 reaches main, this rebase collapses to a no-op.
…e_ptr<FunctionData> in Copy()
GCC + DuckDB 1.4.4's unique_ptr does not implicitly convert
derived->base, so 'return r;' in BinsBindData::Copy() fails to compile:
error: could not convert 'r' from 'unique_ptr<duckdb::{anonymous}::BinsBindData,...>'
to 'unique_ptr<duckdb::FunctionData,...>'
Use duckdb's unique_ptr_cast helper (from duckdb/common/helper.hpp) to
do the conversion explicitly, matching the canonical pattern used by
DuckDB core (e.g. table_scan.hpp's TableScanBindData::Copy()). No
behaviour change; the move is exactly what the implicit conversion
would have done if the compiler accepted it.
Member
Author
|
Linux amd64 + arm64 both PASS after the polyfill stack — the probe itself does not break the baseline. The actual MinGW probe ( |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacks on #170. A probe PR: drop
windows_amd64_mingwfrom the production CIexclude_archsand let CI tell us whether the MEOS vcpkg port builds end-to-end under MinGW.Why MinGW is the most-likely-to-just-work Windows path
The MobilityDuck CI comment lists two source-level blockers for the MEOS vcpkg port on Windows:
<dirent.h>include (used bypostgres/timezone/pgtz.candpostgres/common/pgfnames.c)__attribute__syntaxBoth blockers are absent on the MinGW path. The MEOS vcpkg port should therefore build under MinGW with no source changes.
Two outcomes
windows_amd64_mingwexclusion stays dropped; this PR lands as-is.windows_amd64_mingwback in the exclusion list with a comment naming the specific failure.Independent of
pg_attribute_unused()macro fix) — addresses the one remaining direct__attribute__((__unused__))use in MEOS code; matters for MSVC native Windows, not for MinGW (which accepts the direct syntax).Tracker
<dirent.h>shim; bigger lift; tracked by MobilityDB #513