Build failure with GCC 14 on riscv64 (Ubuntu 24.04) due to use of libstdc++ internal details
🐞 Bug Report
Environment
- Architecture: riscv64 (emulated via QEMU)
- OS: Ubuntu 24.04
- Compiler: g++ 14
-
C++ Standard:
gnu++20 - Folly version: main/master branch (latest)
Problem Description
When attempting to build the Folly library in a QEMU-emulated riscv64 environment running Ubuntu 24.04 with GCC 14, the build process fails with multiple compilation errors across different files. The errors suggest that Folly is relying on non-standard, internal implementation details of GCC's libstdc++ that have been changed or deprecated in version 14.
Error Logs
Multiple files fail to compile. Here are two examples:
1. Error in folly/concurrency/test/AtomicSharedPtrTest.cpp
/root/folly/folly/concurrency/detail/AtomicSharedPtr-detail.h:142:44: error: pointer to member type ‘folly::detail::shared_ptr_internals::shared_count’ {aka ‘std::__shared_count<__gnu_cxx::_S_atomic>’} incompatible with object type ‘std::shared_ptr<const void>’
142 | return (ptr.*fieldPtr(access_shared_ptr{})).*fieldPtr(access_base{});
| ^
(... plus other related errors in the same file)
2. Error in folly/container/test/ForeachTest.cpp
/root/folly/folly/container/test/ForeachTest.cpp:317:31: error: use of built-in trait ‘__type_pack_element<I, T ...>’ in function signature; use library traits instead
317 | type_pack_element_t<I, T...>& get(LargeTuple<T...>&) {
| ^~~
/root/folly/folly/container/test/ForeachTest.cpp:318:39: error: use of built-in trait ‘__type_pack_element<I, T ...>’ in function signature; use library traits instead
318 | static type_pack_element_t<I, T...> elem;
| ^~~~
Analysis
These distinct errors point to a common root cause: a dependency on non-standard, internal implementation details of GCC's libstdc++, which are no longer valid in GCC 14.
-
The
AtomicSharedPtrerror indicates that the code is trying to directly access internal members ofstd::shared_ptr, whose layout has likely changed in the new version of the standard library. This is a fragile approach that is prone to breaking with compiler updates. -
The
ForeachTest.cpperror is even more explicit. It flags the use of__type_pack_element, which is a compiler-internal (built-in) trait. Newer versions of GCC are stricter about disallowing the use of such internal mechanisms, requiring the use of standard library equivalents likestd::tuple_element_tinstead.
I'm circumventing this issue by adding !FOLLY_RISCV64 to macros wrapping affected code, but I haven't verified if this allows tests to pass.
Hi, this is my first time building folly, and I have same issue . GCC 15.2 , Rocky Linux 9 , C++20
/folly/folly/container/test/ForeachTest.cpp:317:31: error: use of built-in trait ‘__type_pack_element<I, T ...>’ in function signature; use library traits instead 317 | type_pack_element_t<I, T...>& get(LargeTuple<T...>&) { | ^~~ /folly/folly/container/test/ForeachTest.cpp:318:39: error: use of built-in trait ‘__type_pack_element<I, T ...>’ in function signature; use library traits instead 318 | static type_pack_element_t<I, T...> elem;
Hi @aleksandar-vukajlovic-igt-com, thank you so much for your comment! It's very helpful to have confirmation that this build failure also occurs on GCC 15.2 on Rocky Linux.
As the author of this issue, I've already submitted a pull request with a fix, which you can find here: #2499
The PR is currently waiting for review from the maintainers. I will keep this issue open and linked to the PR until the fix is merged into the main branch.
Thanks again for your valuable input!
Thanks for patch. Now it compiles and installs without issues.
The build failure isn't actually due to any layout or implementation details changing in std::shared_ptr. The friend template injection magic assumes a lock policy of atomic, which isn't the default for libstdc++ on riscv.
Same issue compiling /folly/folly/container/test/ForeachTest.cp on Fedora 42 with gcc 15.2