On Thu, Jun 19, 2025 at 10:49 PM Casey Bodley <cbodley@xxxxxxxxxx> wrote:
On Thu, Jun 19, 2025 at 6:42 AM kefu chai <tchaikov@xxxxxxxxx> wrote:
>
>
>
> On Thu, Jun 19, 2025 at 1:49 PM Casey Bodley <cbodley@xxxxxxxxxx> wrote:
>>
>> ubuntu 22.04 (jammy) goes end-of-life before the tentacle release
>> will, so the U release can finally drop support. we could do that on
>> main as soon as we have full support for ubuntu 24.04 (noble)
>>
>> that support for jammy has left our package builds pinned to gcc-12,
>> but noble goes up to gcc-14. according to
>> https://en.cppreference.com/w/cpp/compiler_support.html#cpp23, that's
>> likely good enough to make the switch to c++23
>
>
> just wanted to note that we might also want to take clang versions into
> consideration, if we care about both the C++23 support of both standard library
> and compiler. because we are using clang in our CI and windows build.
> the standard library is libstdc++ under most circumstances, while the latter
> could be clang++ for windows build and make check workflows or g++
> for building rpm and deb packages.
>
> FWIW, https://github.com/ceph/ceph/pull/63797 was created to bump up
> the clang version used in windows builds.
thanks, i wasn't considering windows at all
after the merge of https://github.com/ceph/ceph/pull/61740, 'make
check' is getting clang-19 packages from a llvm repo so isn't
restricted by the distro version.
yeah, but we are not using run-make.sh to perform win32 build.
is there any concern about c++23 support for clang-19?
no at all. i just wanted to put more facts on the table, as you mentioned the compiler version in the first mail in this thread, i guess it might be important to add that clang is also used in our pipeline. more specifically, window build is still using clang-16.
i imagine that would still be using the
libstdc++ from gcc-12
yes.
>
>>
>>
>> has anyone experimented with c++23 in ceph? our previous upgrades to
>
>
> i gave it a try couple days ago. the tree compiled just fine with following patch:
>
> diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
> index 5faed469589..532bafabd6a 100644
> --- a/src/CMakeLists.txt
> +++ b/src/CMakeLists.txt
> @@ -242,7 +242,7 @@ if(HAVE_INTEL)
> endif()
>
> # require c++20
> -set(CMAKE_CXX_STANDARD 20)
> +set(CMAKE_CXX_STANDARD 23)
> set(CMAKE_CXX_EXTENSIONS OFF)
> set(CMAKE_CXX_STANDARD_REQUIRED ON)
> set(CMAKE_C_STANDARD 99)
>
>>
>> c++17 and 20 took a considerable effort, so now is probably a good
>> time to start planning for this. we won't be able to switch over until
>
>
> probably we can switch to C++23 sooner? after addressing the warnings,
> i think we should be able to switch to C++23, as long as we don't use
> features only supported by the newer clang++ and g++ compilers and
> libstdc++.
that's great. if gcc-12 compiles successfully as c++23, we could
enable it sooner. i guess the github 'make check's are the only place
we use -Werror?
yes, we added it in ba5d5488.
if so, addressing all warnings for clang-19 should be sufficient
agreed.
BTW, gcc-15 also compiles with some changes. i sent some more patches yesterday. some 3rd party python modules used for testing dashboard do not compile with GCC-15, as they are pinned to ancient versions. they will need to be attended.
>
>>
>>
>>
>> we've dropped jammy everywhere on main (jenkins checks, shaman
>> builds), but we can start merging fixes in the meantime. there will
>> surely be some compiler warnings to address
>
>
> i've sent a couple patches along the way. most of them address the deprecation of
> std::aligned_storage_t .
thank you!
>
>>
>> _______________________________________________
>> Dev mailing list -- dev@xxxxxxx
>> To unsubscribe send an email to dev-leave@xxxxxxx
>
>
>
> --
> Regards
> Kefu Chai
Regards
Kefu Chai
Kefu Chai
_______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
