thisisnic commented on issue #40389: URL: https://github.com/apache/arrow/issues/40389#issuecomment-5646291555
Note: the analysis below is from Claude (AI-assisted, working from the log in this issue and the Arrow source); I haven't reproduced it independently, so treat it as a strong hypothesis rather than confirmed. Root cause: this doesn't look like a Windows → macOS problem, it's a header/library mismatch on the macOS side. The install log shows RE2 was built from source (bundled 2022-06-01), but the missing symbol `re2::re2_internal::Parse<std::string_view>` can only come from compiling against a newer RE2 header (2023-06-01+, where `StringPiece` is `absl::string_view` = `std::string_view`). That header came from Homebrew: xsimd and utf8proc were resolved from `/opt/homebrew`, which put `/opt/homebrew/include` on the include path ahead of the bundled RE2 include dir, so `re2/re2.h` was picked up from Homebrew's RE2 while the bundled 2022 static lib was linked. Static linking plus R's dynamic-lookup link on macOS means the mismatch only surfaces at `dyn.load()`. Windows → Linux worked only because the r-base Docker image had no system RE2 to shadow the bundled headers. macOS → macOS was never tested and would presumably have failed the same way. Underlying issue is in the C++ cmake dependency resolution: with `ARROW_DEPENDENCY_SOURCE=AUTO`, a bundled dependency's headers aren't guaranteed to take precedence over a same-named header in a directory added for some other system dependency. This still applies today since we bundle RE2 2023-03-01 (pre-Abseil) and Homebrew ships a newer one. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
