Vendor xerces#12
Conversation
Adds third_party/xerces-c (pinned to tag v3.2.5; the xercesc_3_2 ABI namespace is hard-coded across ORCA so the 3.3.x line cannot be used without a source migration) and a new PG_ORCA_BUNDLED_XERCES CMake option (default ON) that builds it as a static archive folded into pg_orca.so. The system-xerces pkg-config / manual search path is kept as a fallback when the option is set to OFF. CPack deb/rpm drop the libxerces-c runtime dependency in bundled mode, so the resulting package installs cleanly on hosts without an external xerces-c (e.g. self-hosted Supabase, distroless containers).
CPackConfig.cmake now hard-errors when PG_ORCA_BUNDLED_XERCES=OFF, so release packages can never accidentally ship with a runtime libxerces-c dependency that may be absent on the target host (Ubuntu 24.04's t64 rename, RHEL 9, Supabase / distroless images). The previously conditional deb/rpm Depends/Requires lines collapse to the bundled-only form. build-packages.sh passes -DPG_ORCA_BUNDLED_XERCES=ON explicitly so stale cache values cannot disable bundling.
|
Seems you are using me but didn't get OPENAI_API_KEY seted in Variables/Secrets for this repo. you could follow readme for more information |
actions/checkout does not pull submodules by default, so the workflows hit "PG_ORCA_BUNDLED_XERCES=ON but third_party/xerces-c/CMakeLists.txt is missing" during cmake configure on every job. Add submodules: recursive to all seven checkout invocations across build.yml and package.yml.
|
Seems you are using me but didn't get OPENAI_API_KEY seted in Variables/Secrets for this repo. you could follow readme for more information |
…onverter) The previous unconditional transcoder=gnuiconv broke the macOS CI job because gnuiconv is glibc-specific. Apple builds need macosunicodeconverter (CoreServices). Linux keeps gnuiconv. Either choice avoids pulling in ICU as a runtime dep.
|
Seems you are using me but didn't get OPENAI_API_KEY seted in Variables/Secrets for this repo. you could follow readme for more information |
orca_core only got xerces headers via target_include_directories
(${XERCES_INCLUDE}), which is empty in the bundled path. Linux builds
silently picked up the headers from the system /usr/include because
libxerces-c-dev was present on the dev box; the macOS CI runner has no
system xerces, so libnaucrates failed with "xercesc/sax2/DefaultHandler.hpp
file not found".
Add target_link_libraries(orca_core PUBLIC ${XERCES_LIB}) so the
bundled xerces-c target's PUBLIC INTERFACE_INCLUDE_DIRECTORIES
propagates into orca_core's compile lines. OBJECT libs have accepted
target_link_libraries since CMake 3.12 — no link happens, only usage
requirements flow through.
|
Seems you are using me but didn't get OPENAI_API_KEY seted in Variables/Secrets for this repo. you could follow readme for more information |
Release packages are Linux-only, and macOS dev builds already pull xerces-c from Homebrew with no fuss. Static-linking xerces-c into a .so on the Apple toolchain has its own quirks (transcoder selection, visibility, codesigning) that aren't worth working through when the bundled path serves no deployment goal on that platform. Default PG_ORCA_BUNDLED_XERCES to OFF when CMAKE_HOST_APPLE / APPLE is true; remain ON elsewhere. The macOS CI already brew-installs xerces-c so no workflow change is needed. Either value can still be forced via -DPG_ORCA_BUNDLED_XERCES=...
|
Seems you are using me but didn't get OPENAI_API_KEY seted in Variables/Secrets for this repo. you could follow readme for more information |
…unicodeconverter)" This reverts commit 4646ab1.
|
Seems you are using me but didn't get OPENAI_API_KEY seted in Variables/Secrets for this repo. you could follow readme for more information |
No description provided.