GH-49371: [C++] Work around bit_width not being available on MacOS's partially compatible C++20 build#49405
Conversation
|
@github-actions crossbow submit test-r-macos-as-cran |
|
Revision: 632cb49 Submitted crossbow builds: ursacomputing/crossbow @ actions-3e29779128
|
|
@github-actions crossbow submit test-r-macos-as-cran |
|
Revision: 5b6a759 Submitted crossbow builds: ursacomputing/crossbow @ actions-971ec12679
|
|
@github-actions crossbow submit test-r-macos-as-cran |
|
Revision: 5ea627b Submitted crossbow builds: ursacomputing/crossbow @ actions-c0a2135a7a
|
|
The CI failures look like they are #49347 which is also on main. |
|
The failing build #49391 (comment) has compiler version "The CXX compiler identification is AppleClang 17.0.0.17000013" The build that originally succeeded #49298 (comment) was using "using C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.0.13.5)’" and this one is using the same one "using C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.0.13.5)’" so I'm not certain that the success of this build is due to the changes made. Looks like the workflow is changing here. The build that failed before this one here was also using "-- The CXX compiler identification is AppleClang 17.0.0.17000013". Looks like Ursa Computing is running two diifferent runners and one them may have an outdated workflow definition. |
kou
left a comment
There was a problem hiding this comment.
+1
#49405 (comment) was failed with "AppleClang 17.0.0.17000013":
https://github.com/ursacomputing/crossbow/actions/runs/22473809318/job/65096433688#step:9:56
-- The CXX compiler identification is AppleClang 17.0.0.17000013
https://github.com/ursacomputing/crossbow/actions/runs/22473809318/job/65096433688#step:9:1774
/Users/runner/work/crossbow/crossbow/arrow/cpp/src/parquet/chunker_internal.cc:89:27: error: no member named 'bit_width' in namespace 'std'
89 | auto target_bits = std::bit_width(static_cast<uint64_t>(target_size));
| ~~~~~^
And the last try succeeded: #49405 (comment)
So this change fixes this problem.
BTW, I think that the important part of this problem is libc++ version not clang version. So I think that the clang version difference isn't important here.
|
so libc++ is included in MacOSX11.3.1.sdk which is the same across runners and isn't versioned with the compiler? |
|
Yes. |
|
@kou is exactly right here. Further: looking at when the |
Fixes #49371
Rationale for this change
Stop main from failing
What changes are included in this PR?
Thanks Kou for the suggestion at #49391 (comment)
Are these changes tested?
Yes
Are there any user-facing changes?
No
bit_widthnot being available on MacOS's partially compatible C++20 build #49371