Skip to content

branch-4.0: [Fix](thirdparty) Unify arrow cpp standard with be (#64390) - #66723

Merged
morningman merged 1 commit into
apache:branch-4.0from
HappenLee:backport-pr-64390-branch-4.0-v2
Aug 13, 2026
Merged

branch-4.0: [Fix](thirdparty) Unify arrow cpp standard with be (#64390)#66723
morningman merged 1 commit into
apache:branch-4.0from
HappenLee:backport-pr-64390-branch-4.0-v2

Conversation

@HappenLee

@HappenLeeHappenLee commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

cherry-pick: #64390

This supersedes #64810. After #64810 was opened, #63266 was merged into branch-4.0 and added apache-arrow-17.0.0-status-inline-static-fix.patch. As a result, #64810 no longer contains the complete applicable diff from #64390: it enables C++20 for Arrow but leaves the temporary Arrow Status patch in place.

This backport is based on the latest branch-4.0. It enables C++20 for thirdparty/Arrow and removes the temporary Arrow Status patch and its application logic, matching the intent of #64390. The Paimon-cpp changes are intentionally omitted because branch-4.0 does not contain Paimon-cpp.

Validation:

  • bash -n thirdparty/build-thirdparty.sh
  • bash -n thirdparty/download-thirdparty.sh
  • git diff --check apache/branch-4.0...HEAD

@linrrzqqq@HappenLee
[Fix](thirdparty) Unify arrow cpp standard with be (apache#64390)
2d351fd
Related PR: apache#63191
Problem Summary:
Arrow 17 defaults to `C++17` when CMAKE_CXX_STANDARD is not specified,
while Doris BE is built with `C++20`. This can make header-defined
inline/template code from Arrow Flight and its dependencies be compiled
under different C++ standard modes in the same final binary.
In particular, Arrow Status-related inline paths may generate different
implementations across C++17 and C++20, such as different initialization
strategies for function-local static std::string objects:
code:
```cpp
const std::string& get_empty_string() {
static const std::string s = "";
return s;
}
```
cpp17 lazy initialization:
```asm
get_empty_string[abi:cxx11]():
push rbp
mov rbp, rsp
sub rsp, 64
cmp byte ptr [rip + guard variable for get_empty_string[abi:cxx11]()::s[abi:cxx11]], 0
jne .LBB0_4
lea rdi, [rip + guard variable for get_empty_string[abi:cxx11]()::s[abi:cxx11]]
call __cxa_guard_acquire@PLT
cmp eax, 0
je .LBB0_4
lea rdx, [rbp - 33]
mov qword ptr [rbp - 32], rdx
mov rax, qword ptr [rbp - 32]
mov qword ptr [rbp - 8], rax
lea rdi, [rip + get_empty_string[abi:cxx11]()::s[abi:cxx11]]
lea rsi, [rip + .L.str]
call std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>::basic_string<std::allocator<char>>(char const*, std::allocator<char> const&)
jmp .LBB0_3
.LBB0_3:
lea rax, [rbp - 33]
mov qword ptr [rbp - 24], rax
mov rdi, qword ptr [rbp - 24]
call std::__new_allocator<char>::~__new_allocator() [base object destructor]
lea rdi, [rip + std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>::~basic_string() [base object destructor]]
lea rsi, [rip + get_empty_string[abi:cxx11]()::s[abi:cxx11]]
lea rdx, [rip + __dso_handle]
call __cxa_atexit@PLT
lea rdi, [rip + guard variable for get_empty_string[abi:cxx11]()::s[abi:cxx11]]
call __cxa_guard_release@PLT
```
cpp20 constant initialization:
```asm
get_empty_string[abi:cxx11]():
push rbp
mov rbp, rsp
lea rax, [rip + get_empty_string[abi:cxx11]()::s[abi:cxx11]]
pop rbp
ret
get_empty_string[abi:cxx11]()::s[abi:cxx11]:
.quad get_empty_string[abi:cxx11]()::s[abi:cxx11]+16
.quad 0
.zero 16
```
Mixing those definitions through `weak/COMDAT` symbols is not a
supported build model and can surface as runtime crashes in Flight
error/status handling paths.
@hello-stephen

hello-stephen commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@yiguolei

yiguolei commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

run buildall

@morningman

morningman commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

skip buildall

@github-actionsgithub-actionsBot added the approved Indicates a PR has been approved by one committer. label Aug 13, 2026
@github-actions

github-actionsBot commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

PR approved by at least one committer and no changes requested.

@github-actions

github-actionsBot commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

PR approved by anyone and no changes requested.

@morningman
morningman merged commit 62a5f87 into apache:branch-4.0Aug 13, 2026
33 of 34 checks passed
@hello-stephen

hello-stephen commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

BE UT Coverage Report

Increment line coverage 🎉

Increment coverage report
Complete coverage report

CategoryCoverage
Function Coverage53.63% (19647/36633)
Line Coverage36.70% (184108/501673)
Region Coverage33.19% (142867/430432)
Branch Coverage34.09% (61822/181367)

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@morningmanmorningmanmorningman approved these changes
@yiguoleiyiguoleiyiguolei approved these changes

Assignees

No one assigned

Labels

approvedIndicates a PR has been approved by one committer.reviewed

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@HappenLee@hello-stephen@yiguolei@morningman@linrrzqqq