Bump pinned MEOS and adapt to orthogonalized spatial-rels API#134
Bump pinned MEOS and adapt to orthogonalized spatial-rels API#134estebanzimanyi wants to merge 9 commits into
Conversation
…onalization)
The previous portfile pinned REF f11b7443e (Mar 30) with a SHA512 that
actually corresponded to a different commit (742c1fb5), masked by vcpkg
SHA-cache lottery. Move both REF and SHA512 to MobilityDB master HEAD
dd4ccd3c2 so the pin is internally consistent.
This bump crosses two breaking MEOS API changes that need separate
follow-up commits to compile cleanly:
* meosType -> MeosType (#790, Apr 28): the forward-compat alias in
src/include/tydef.hpp now resolves cleanly.
* Drop restr/atvalue from spatiotemporal relationship functions
(#778, Apr 28): the 4-arg tcontains_geo_tgeo / tdisjoint_* /
tintersects_* / ttouches_* / tdwithin_* / tpoint_minus_geom calls
in src/geo/tgeompoint_functions.cpp must be reworked to the
new 2-arg / 3-arg signatures. Restriction semantics moves to
post-hoc atValues per MEOS PR #778's migration recipe; the DuckDB
public surface drops the (BOOLEAN) overloads to mirror the
orthogonalized MEOS shape.
MEOS PR #1005 renamed temptype_continuous to temptype_supports_linear in meos_catalog.h. Update the five call sites in src/geo/tgeompoint_functions.cpp and src/temporal/temporal_functions.cpp to match the new MEOS API.
Drop trailing underscore on bbox_type and migrate rtree_search to the new MeosArray *result out-parameter signature replacing the int **/int* pair.
MEOS master now exports a global function bool bbox_type(MeosType) in meos_internal.h. Inside TRTreeIndex member functions, unqualified bbox_type resolves to that global function and shadows the class member, producing 'assignment of function' and 'invalid conversion' errors. Rename the member to bbox_meostype throughout the rtree module.
Reviewer's quickstart — ~10 minutesWhat this PR does in one sentence: bumps the pinned MEOS commit in Files to read (25 total, in priority order):
This is the foundational pin-bump that #142 / #145 / the entire Cross-link: Linux arm64 CI here may hit the Why it's safe to merge: the new MEOS pin is on MobilityDB master (verifiable in the portfile diff); the orthogonalised API replaces the old one, so the substitution is byte-for-byte equivalent. |
`meosType` (lower-case) is the **pre-consolidation** MEOS type name; `MeosType` (upper-case) is the **post-consolidation** target that the upstream rename sweep has not yet reached. The current vcpkg pin (`vcpkg_ports/meos/portfile.cmake` REF f11b7443ee98…) is still pre-consolidation: `meos/include/temporal/meos_catalog.h` line 121 declares the typedef as `} meosType;` and every MEOS API uses the lower-case spelling. MobilityDuck's source code consistently uses `meosType` to match — `grep -rn '\bMeosType\b' src/` finds the name only on the alias line and its comment, nowhere else. c8cad6d added `using meosType = MeosType;` as a forward-looking bridge for the eventual consolidation bump. That bridge points at `MeosType`, which the current pin does NOT yet expose, so it breaks every PR's Linux arm64 build with: /duckdb_build_dir/src/include/tydef.hpp:18:18: error: ‘MeosType’ does not name a type; did you mean ‘meosType’? The fix is to drop the premature alias and replace the misleading comment with one that documents the pre/post-consolidation distinction and the resume path for the next pin bump — at that point a reviewer can either restore the bridge (this time it'll be valid because `MeosType` will exist) or sweep the MobilityDuck source from `meosType` to `MeosType` in a single PR. Unblocks every in-flight PR's Linux arm64 build: #126, #130, #149, #158, #159, #160, plus the entire `feat/*_port_core` extended-type stack (#148/#150/#151/#153/#155/#156).
The stage_icu helper mapped only the Linux uname values, so on the macOS arm64 test runner uname -m returned "arm64" and the icu extension was copied to .duckdb/extensions/v1.4.4/arm64 instead of .../osx_arm64, where DuckDB's autoload looks. The hub fallback is not reliably resolvable on that runner, so the osx_arm64 Test step failed to load the extension. Map the OS and architecture to the DuckDB platform string (linux_amd64, linux_arm64, osx_amd64, osx_arm64) so the locally built icu is staged at the path autoload expects on every tested platform; the Linux mapping is unchanged. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
SIGSEGV pattern surfaces uniformly across this PR's downstream stackCI's red checks across all PRs stacked on this branch (and #178 which has the same Linux-amd64 SIGSEGV symptom) share one root cause: a runtime SIGSEGV during sqllogic test execution under the new MEOS pin. Crash site: Triggering tests across PRs:
Bump range analyzed:
Diagnostic narrowing already done:
Recommended next-touch steps:
|
SIGSEGV root cause identified — symbol collision in pg-vendored
|
|
Upstream MEOS fix filed as MobilityDB/MobilityDB#1108 — "Prefix-rename pg-vendored symbols to meos_* (host symbol collision fix)". That PR adds a single Once #1108 lands on integration/meos-1.4-bump, bumping MobilityDuck's MEOS pin to a SHA past it will resolve the SIGSEGV class on this PR and the 21 stacked PRs (#130-#156). Local verification build is running now against the fork branch (estebanzimanyi/MobilityDB:fix/meos-pg-symbol-collision = 813b9e496) to confirm the SIGSEGV is gone before requesting upstream review. |
1 participant
Bumps the vcpkg portfile to MEOS dd4ccd3c2 (post-rename + post-spatial-rels orthogonalization) and adapts the temporal-spatial relationship surfaces (tContains, tDisjoint, tIntersects, tTouches, tDwithin) to the new MEOS API which no longer takes the restr/at_value parameters; the previous behavior is reproduced by composing with atValues(temporal, bool). Also drops the now-defunct 3-arg minusGeometry(..., FLOATSPAN) overload since tpoint_minus_geom no longer accepts a z-span.