#3 Correctly build as C++17 instead of C++11 for gtest-1.13.0, which needs C++14
Merged a year ago by sergiomb. Opened a year ago by music.
rpms/ music/libphonenumber gtest-1.13.0  into  rawhide

file modified
+11 -4
@@ -1,6 +1,6 @@ 

  Name: libphonenumber

  Version: 8.12.57

- Release: 5%{?dist}

+ Release: 6%{?dist}

  Summary: Library to handle international phone numbers

  # The project itself is ASL 2.0 but contains files from Chromium which are BSD and MIT.

  License: ASL 2.0 and BSD and MIT
@@ -37,20 +37,24 @@ 

  

  %prep

  %autosetup -p1

+ # Gtest 1.13.0 requires at least C++14; C++17 matches how abseil-cpp is built;

+ # simply setting -DCMAKE_CXX_STANDARD=17 does not override this in practice.

+ sed -r -i 's/\b(CMAKE_CXX_STANDARD[[:blank:]]+)11\b/\117/' \

+     cpp/CMakeLists.txt tools/cpp/CMakeLists.txt

  

  

  %build

  pushd cpp

- # CXX_STANDARD=17 fixes undefined reference to `absl::lts_20210324::StrReplaceAll(std::initializer_list<std::pair<absl::lts_20210324::string_view

  %ifarch %{java_arches}

- %cmake -DCMAKE_CXX_STANDARD=17

+ %cmake

  %else

  touch src/phonenumbers/test_metadata.h

- %cmake -DCMAKE_CXX_STANDARD=17 -DREGENERATE_METADATA=OFF

+ %cmake -DREGENERATE_METADATA=OFF

  %endif

  %cmake_build

  popd

  

+ 

  %install

  pushd cpp

  %cmake_install
@@ -73,6 +77,9 @@ 

  

  

  %changelog

+ * Mon Jan 30 2023 Benjamin A. Beasley <code@musicinmybrain.net> - 8.12.57-6

+ - Correctly build as C++17 instead of C++11 for gtest-1.13.0, which needs C++14

+ 

  * Thu Jan 19 2023 Fedora Release Engineering <releng@fedoraproject.org> - 8.12.57-5

  - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild

  

With gtest 1.13.0, now in Rawhide, C++14 or later is required.

This package’s spec file was asking for C++17, but it wasn’t working as expected; the sources were still compiled with -std=gnu++11.

Fixes FTBFS in Rawhide/F38 with gtest 1.13.0.

Pull-Request has been merged by sergiomb

a year ago

thanks , and what do you think about update libphonenumber to 8.13 ? the update only can be made in rawhide ?

thanks , and what do you think about update libphonenumber to 8.13 ? the update only can be made in rawhide ?

I have no idea. I don’t really have any experience with this package. Upstream sets SONAME based on the major version only, which suggests it is supposed to be a compatible update, but C++ ABI compatibility is hard, so you would probably have to use an ABI diff tool to be sure.

change from libphonenumber.so.8.12 to libphonenumber.so.8.13

one function changed , is enough to force one mass rebuild ?

Thank you

abipkgdiff --d1  libphonenumber-debuginfo-8.12.57-6.fc37.x86_64.rpm --d2 /var/lib/mock/fedora-37-x86_64/result/libphonenumber-debuginfo-8.13.6-1.fc37.x86_64.rpm libphonenumber-8.12.57-6.fc37.x86_64.rpm /var/lib/mock/fedora-37-x86_64/result/libphonenumber-8.13.6-1.fc37.x86_64.rpm
================ changes of 'libphonenumber.so.8.12'===============
Functions changes summary: 0 Removed, 1 Changed (186 filtered out), 0 Added functions
Variables changes summary: 0 Removed, 0 Changed (2 filtered out), 0 Added variables

1 function with some indirect sub-type change:

[C] 'method i18n::phonenumbers::PhoneMetadata* google::protobuf::Arena::CreateMaybeMessage<i18n::phonenumbers::PhoneMetadata>()' at phonemetadata.pb.cc:2610:1has some indirect sub-type changes:
return type changed:
in pointed to type 'class i18n::phonenumbers::PhoneMetadata' at phonemetadata.pb.h:546:1:
type size hasn't changed
2 member function insertions:
'method virtual i18n::phonenumbers::PhoneMetadata::~PhoneMetadata(int)' at phonemetadata.pb.cc:1290:1    {_ZN4i18n12phonenumbers13PhoneMetadataD0Ev}
'method virtual i18n::phonenumbers::PhoneMetadata::~PhoneMetadata(int)' at phonemetadata.pb.cc:1290:1    {_ZN4i18n12phonenumbers13PhoneMetadataD2Ev}
no member function changes (12 filtered);
1 data member deletion:
'bool leading_zero_possible_', at offset 2224 (in bits) at phonemetadata.pb.h:1282:1
1 data member change:
'bool mobile_number_portable_region_' offset changed from 2232 to 2224 (in bits) (by -8 bits)

================ end of changes of 'libphonenumber.so.8.12'===============

change from libphonenumber.so.8.12 to libphonenumber.so.8.13

one function changed , is enough to force one mass rebuild ?

Given that the layout of PhoneMetadata (visible to API users via /usr/include/phonenumbers/phonemetadata.pb.h) has changed, it looks like this is an unintentional ABI change, and a rebuild of dependent packages would be appropriate. The members that moved around are private, but the accessors are inline and would be compiled into the dependent packages, which means they will read and write the wrong locations if the dependent packages are not recompiled.

If metadata changes are affecting the C++ ABI, that suggests upstream’s habit of using the major version as the .so version is probably not correct, and they probably should not be implying C++ ABI stability across even patch releases. I’m not personally in the mood to go discuss this with them.

Metadata