fix(build): disable glog unwind without libunwind

[mrdrivingduck]

Purpose

Linked issue: N/A

This is a follow-up to #60. That change fixed static-link errors in regular configurations by adding a discovered libunwind library to the imported glog target's link interface. However, it made that decision after bundled glog had already been configured, so an explicit LIBUNWIND_LIBRARY=FALSE setting was not propagated to glog.

A downstream build can explicitly set -DLIBUNWIND_LIBRARY=FALSE to prevent paimon-cpp from using or propagating libunwind. Before this change, paimon-cpp skipped adding libunwind to the imported glog target, but glog still used its default unwind auto-detection. When libunwind was installed and discoverable by glog's CMake configuration, glog enabled libunwind support and compiled stacktrace code with unw_* references.

The inconsistency becomes visible when a downstream application links the resulting static glog library: paimon-cpp does not propagate -lunwind, while glog contains calls that require it, which can produce unresolved unw_* symbols. Downstream users must then carry a glog-specific patch or otherwise override glog's unwind configuration.

Use the same LIBUNWIND_LIBRARY result for both decisions. When libunwind is unavailable or explicitly disabled, pass -DWITH_UNWIND=none to bundled glog and omit the libunwind link dependency. Otherwise, retain the existing automatic discovery and linking behavior.

Tests

• cmake --build build --target glog_ep -j 4
• pre-commit run --files cmake_modules/ThirdpartyToolchain.cmake
• git diff --check

API and Format

No public API, storage format, or protocol changes.

Documentation

No documentation changes.

Generative AI tooling

Generated-by: Codex GPT-5.6 Terra

[mrdrivingduck]

Additional note from testing: I could not reproduce the unresolved libunwind symbols on macOS, while the issue is reproducible on Linux.

This appears to be due to different linker and loader behavior for undefined symbols. When producing a .dylib, macOS ld64 can tolerate the unw_* references and defer their resolution until dynamic loading, so both the library build and extension loading may succeed. Linux exposes the missing libunwind dependency earlier during linking.

Therefore, a successful macOS build does not make the configuration consistent. When LIBUNWIND_LIBRARY=FALSE, bundled glog should still receive -DWITH_UNWIND=none rather than auto-detecting and enabling libunwind.

[Copilot]

Pull request overview

This PR aligns bundled glog’s unwind configuration with the top-level LIBUNWIND_LIBRARY decision so that explicitly disabling or lacking libunwind doesn’t result in glog being built with unw_* references that downstream linkers can’t satisfy.

Changes:

• Moves find_library(LIBUNWIND_LIBRARY ...) earlier in build_glog() so the result is available during glog’s CMake configuration.
• When LIBUNWIND_LIBRARY is not found or explicitly disabled (e.g. -DLIBUNWIND_LIBRARY=FALSE), passes -DWITH_UNWIND=none to bundled glog.
• Preserves the existing behavior of adding libunwind to glog’s imported target link interface when it is available.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[zjw1111]

Thanks for the follow-up! The fix is well-reasoned: making both glog's WITH_UNWIND setting and paimon's link propagation derive from the same LIBUNWIND_LIBRARY result resolves the unresolved unw_* symbols cleanly, and -DWITH_UNWIND=none is a valid driver value for glog v0.7.1. +1