Latest upstream release: 20210324.1 Current version/release in rawhide: 20200923.3-1.fc35 URL: https://github.com/abseil/abseil-cpp Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/115295/
Currently, abseil-cpp is built with C++17 ABI. See https://github.com/abseil/abseil-cpp/blob/master/FAQ.md#what-is-abi-and-why-dont-you-recommend-using-a-pre-compiled-version-of-abseil, where upstream discusses the issue, and the first few lines of https://src.fedoraproject.org/rpms/grpc/blob/ce88e016403acd1ee9844558136a0c5a7e80ed1e/f/grpc.spec, where the C++17 ABI from the abseil-cpp dependency requires me to compile grpc with a C++17 ABI too. In this version, this will have to be an explicit choice (-DCMAKE_CXX_STANDARD=17), as C++11 is now the default. Since dependent programs defaulting to C++11 can usually be compiled as C++17 with few or no changes, maintaining the C++17 status quo is probably the least harmful choice. ----- Here’s a link to the (huge) diff from the version currently in Rawhide: https://github.com/abseil/abseil-cpp/compare/20200923.3...20210324.1 ----- Here’s a bug discussing the new so-version scheme: https://github.com/abseil/abseil-cpp/issues/950 ----- There is a new ABSL_USE_EXTERNAL_GOOGLETEST option that could make it easier to start running the tests.
Thanks for the explanation and pointers to the new CMake config options. I agree that it's probably not harmful to keep building abseil-cpp with the C++17 ABI (the current builds are just using the gcc default standards version), but if there's a compelling reason to switch back to C++11 I'm not opposed to doing that. abseil-cpp doesn't have a lot of dependencies in Fedora at the moment. It should be possible for the abseil-cpp CMake targets to export the cxx_std_17 target_compile_feature, which would help with Bloaty and some of grpc. That feature requires CMake 3.7, so it's unlikely they're using it upstream with CMAKE_MINIMUM_REQUIRED(VERSION 3.5)
Latest upstream release: 20210324.2 Current version/release in rawhide: 20200923.3-1.fc35 URL: https://github.com/abseil/abseil-cpp Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/115295/
Let me know if you run into any problems rebuilding grpc in the side tag. Hopefully, grpc 1.37.1 will rebuild cleanly, and I can do grpc 1.38 (with accompanying rebuilds of grpc’s dependent packages) as a follow-up.
Will do. I rebuilt it locally in mock against the updated abseil-cpp without an issue, I'm hoping that translates to koji as well.
FEDORA-2021-118423702f has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.