Repository navigation
[C++] error: no member named 'log2p1' in namespace 'std' #49841
Description
Describe the bug, including details regarding any error messages, version, and platform.
Apache Arrow 24.0.0 fails to build for me on macOS 12:
/usr/bin/clang++ -DARROW_EXTRA_ERROR_CONTEXT -DARROW_HAVE_RUNTIME_AVX2 -DARROW_HAVE_RUNTIME_AVX512 -DARROW_HAVE_RUNTIME_BMI2 -DARROW_HAVE_RUNTIME_SSE4_2 -DARROW_HAVE_SSE4_2 -DARROW_WITH_TIMING_TESTS -I/opt/local/var/macports/build/apache-arrow-3893d460/work/build/src -I/opt/local/var/macports/build/apache-arrow-3893d460/work/arrow-24.0.0/cpp/src -I/opt/local/var/macports/build/apache-arrow-3893d460/work/arrow-24.0.0/cpp/src/generated -fno-aligned-new -pipe -I/opt/local/libexec/boost/1.81/include -Os -DNDEBUG -I/opt/local/libexec/boost/1.81/include -I/opt/local/include -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -Qunused-arguments -fcolor-diagnostics -Wall -Wno-unknown-warning-option -Wno-pass-failed -msse4.2 -O3 -DNDEBUG -O2 -std=c++20 -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -mmacosx-version-min=12.0 -fPIC -MD -MT src/arrow/CMakeFiles/arrow_array.dir/array/array_decimal.cc.o -MF src/arrow/CMakeFiles/arrow_array.dir/array/array_decimal.cc.o.d -o src/arrow/CMakeFiles/arrow_array.dir/array/array_decimal.cc.o -c /opt/local/var/macports/build/apache-arrow-3893d460/work/arrow-24.0.0/cpp/src/arrow/array/array_decimal.cc
In file included from /opt/local/var/macports/build/apache-arrow-3893d460/work/arrow-24.0.0/cpp/src/arrow/array/array_decimal.cc:18:
In file included from /opt/local/var/macports/build/apache-arrow-3893d460/work/arrow-24.0.0/cpp/src/arrow/array/array_decimal.h:24:
In file included from /opt/local/var/macports/build/apache-arrow-3893d460/work/arrow-24.0.0/cpp/src/arrow/array/array_binary.h:30:
In file included from /opt/local/var/macports/build/apache-arrow-3893d460/work/arrow-24.0.0/cpp/src/arrow/array/array_base.h:26:
In file included from /opt/local/var/macports/build/apache-arrow-3893d460/work/arrow-24.0.0/cpp/src/arrow/array/data.h:33:
/opt/local/var/macports/build/apache-arrow-3893d460/work/arrow-24.0.0/cpp/src/arrow/util/bit_util.h:146:15: error: no member named 'log2p1' in namespace 'std'
return std::log2p1(x - 1);
~~~~~^
1 error generated.
System details:
% sw_vers
ProductName: macOS
ProductVersion: 12.7.6
BuildVersion: 21H1320
% clang++ --version
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
% xcodebuild -version
Xcode 13.4.1
Build version 13F100
bit_width exists in the headers and log2p1 does not:
% grep -E '(bit_width|log2p1)' -r /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/bit: constexpr T bit_width(T x) noexcept; // C++20
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/bit:bit_width(_Tp __t) noexcept
On the same system, Apache Arrow 23.0.1 had built successfully.
Apache Arrow 24.0.0 contains #49570 to fix #49569. I guess in fixing it for macOS 14 it broke for macOS 12.
Instead of having multiple places in the source code where you try to decide between bit_width and log2p1 based on assumed knowledge of compiler capabilities, could you determine it with a cmake test and then use that result throughout?
Component(s)
C++
Activity
[-]error: no member named 'log2p1' in namespace 'std'[/-][+][C++] error: no member named 'log2p1' in namespace 'std'[/+]kou commentedon Apr 27, 2026
Is macOS 12 still supported?
GitHub Actions doesn't provided a macOS 12 based runner now...
https://docs.github.com/en/actions/reference/runners/github-hosted-runners#standard-github-hosted-runners-for-public-repositories
ryandesign commentedon Apr 27, 2026
macOS 12 is just the system I happened to observe it on. It may affect other versions of macOS, and other non-Mac operating systems, as well.
When you ask about support, it's important to qualify that as to who is providing the support. It's true that Apple no longer issues regular updates for macOS 13 or earlier, and it's true that GitHub no longer offers runners for macOS 13 or earlier. However, in February 2026 Apple did issue unexpected minor updates for macOS 10.15 and macOS 11.
Just because the manufacturer no longer supports an OS version doesn't mean that it or the other software on it or the computer it's running on stop working. There are millions of functional Macs with Intel processors out there that cannot be upgraded to the latest macOS versions, merely because Apple decided it should be so. Third-party software developers can make different choices and can continue to offer new versions of their software for older computers.
In the case of the problem I reported, I stand by my suggestion to check for the feature at cmake time by simply asking the compiler (whatever model or version it is) what it supports, and using that result throughout the rest of the code. I think this is both less complex and more reliable than what you're doing now.
kou commentedon Apr 29, 2026
In general, maintenance resources are limited. We can't keep supporting all platforms including platforms that are EOL-ed by upstream.
If you can open a PR for your idea and test it, I can review it.
If nobody works on this for old macOS, we will not do anything for this and remove the
std::log2p1()workaround when CRAN upgrades its macOS. It will also fix this problem.chore(deps): PROJ 9.8.1, expat 2.7.5
GDAL v3.13.3 (#236)
apacheGH-49841: [C++] Fix macOS 12.3 SDK build by using __cpp_lib_int…
apacheGH-49841: [C++] Fix macOS 12.3 SDK build by using __cpp_lib_int…
Merge remote-tracking branch 'origin/main' into apachegh-49841-int-po…
Merge remote-tracking branch 'upstream/main' into apachegh-49841-int-…