ci(probe): drop linux_amd64_musl exclusion — see if MEOS vcpkg port builds against musl-libc#172
Open
estebanzimanyi wants to merge 7 commits into
Open
ci(probe): drop linux_amd64_musl exclusion — see if MEOS vcpkg port builds against musl-libc#172estebanzimanyi wants to merge 7 commits into
estebanzimanyi wants to merge 7 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.
…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.
estebanzimanyi
force-pushed
the
ci/probe-musl-build
branch
from
2a09a9a to
50be644
Compare
… 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 musl probe ( |
Member
Author
|
Probe outcome — musl build SURFACES a real Wave D blocker:
Diagnosis: Alpine/musl ships without Wave D fix paths (any one of these unblocks musl):
Important positive signal: the MEOS C compile + link on musl is green — no source-level musl portability bug. The blocker is purely environmental (missing tzdata). This is a cleaner Wave D unblock than I expected. |
Member
Author
|
Alternative unblock path opened as #182: extension-side fix that skips the |
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 #171 (MinGW probe), which stacks on #170 (osx_arm64). The three probes are independent — one outcome doesn't affect the others.
Same probe shape as #171
The MEOS-port-side glibc-isms are the suspected blockers for musl-libc compatibility:
postgres/utils/formatting.c(musl is stricter about%Lfprecision specifiers)fpos_topacity (musl makes it strictly opaque; glibc allows arithmetic)__GLIBC__-guarded paths in vendored PG sourcesgetlineavailability (POSIX.1-2008; musl supports but with different prototypes)The precise failure log is the data needed to scope the per-blocker fix. This probe lets CI tell us.
Two outcomes
linux_amd64_muslback in the exclusion list with a comment naming the specific failure, and a follow-up PR addresses that blocker.Tracker
osx_arm64windows_amd64_mingwlinux_amd64_muslwindows_amd64(MSVC)<dirent.h>shim + (already-opened) MobilityDB #1104 attribute fix