Heads-up: abseil-cpp 20230125.1 coming to Rawhide/F39

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Wednesday, March 15, 2023, Jonathan Wakely <jwakely@xxxxxxxxxx> wrote:
>
>
> On Wednesday, March 15, 2023, Ben Beasley  wrote:
>> In one week (2023-03-22), or slightly later, I plan to update abseil-cpp[1] in Rawhide/F39 to the latest LTS release, which is currently 20230125.1. Release notes are available[2].
>>
>> The most significant breaking change is that dependent packages are required to compile with C++14 or later, and I have found that users of absl::string_view need C++17 or later.
>
> Hmm, that seems odd. The release notes say C++14 is required but don't mention that C++17 is needed for some components.
>
> C++17 provides std::string_view so what's the point in using absl::string_view at all if it only works when std::string_view is already available?
>
>> This has already been adjusted in a couple of packages (thanks!) and I have one PR still open[3].
>
>
> The error you showed there says the problem is using std::string_view, which does indeed require C++17. That doesn't seem related to absl::string_view, unless there's a bug in abseil which causes absl::string_view to incorrectly use std::string_view in C++14 mode.
>
> I think something doesn't make sense here, and would beworth understanding.

OK, abseil has a macro that says whether to define its own string_view or use the std one:
https://github.com/abseil/abseil-cpp/blob/92ac33b99eb9735a23a5e10150a85ad9d4820065/absl/base/options.h#L127
As you can see in the source code there, the default value is 2, meaning "use std::string_view if available, but fallback to absl's own string_view otherwise" (see the comment for more explanation).

In rawhide today, /usr/include/absl/base/options.h has the default value:
#define ABSL_OPTION_USE_STD_STRING_VIEW 2

But in your new abseil-cpp-devel-20230125.1-1.fc39 package it has a different value:
#define ABSL_OPTION_USE_STD_STRING_VIEW 1

This means that absl::string_view is hardcoded to be an alias for std::string_view, which means it requires C++17. See lines 135 and 136 at the link above:
// A value of 1 means to use an alias to std::string_view. This requires that
// all code using Abseil is built in C++17 mode or later.

This means your new abseil is to blame for the C++17 requirement. For some reason, your new package hardcodes "the compiler supports C++17" to be true, which means it cannot be used by any packages that want to build as C++14. I think your pull request for ilbc is wrong and should not be merged. Instead you should figure out why abseil-cpp now hardcodes that macro to 1, and fix that.







>
>
>>
>> All dependent packages build successfully in COPR[4] (with any necessary C++17 PR’s applied).
>>
>> I will rebuild the following packages in the side tag myself as primary maintainer or as co-maintainer:
>>
>>     - abseil-cpp (of course)
>>
>>     - bear
>>
>>     - fastnetmon
>>
>>     - grpc
>>
>>     - libarrow
>>
>> For the remaining packages that need to be rebuilt, when the new version of abseil-cpp and the rebuilt grpc are ready in the side tag, I will send an email to their maintainers asking them to rebuild into the side tag. After a few days, I will ask Rich Mattes, the primary abseil-cpp package maintainer, to use his provenpackager privileges to rebuild any remaining dependent packages (and merge the C++17 PR for ilbc if it is still open). He has already agreed to do so.
>>
>> If you maintain one of the affected packages and you want me to handle rebuilds in the future, you can grant me privileges on the project; collaborator on the rawhide branch should be sufficient.
>>
>>     - bloaty
>>
>>     - credentials-fetcher
>>
>>     - fcitx5-mozc
>>
>>     - frr
>>
>>     - ilbc
>>
>>     - libphonenumber
>>
>>     - mozc
>>
>>     - plasma-dialer
>>
>>     - qmlkonsole
>>
>>     - spacebar
>>
>> If you maintain one of the affected packages, you should find that you received this message directly (by BCC due to limitations on the number of CC recipients imposed by the devel mailing list).
>>
>> [1] https://src.fedoraproject.org/rpms/abseil-cpp/pull-request/10
>>
>> [2] https://github.com/abseil/abseil-cpp/releases/tag/20230125.1
>>
>> [3] https://src.fedoraproject.org/rpms/ilbc/pull-request/1
>>
>> [4] https://copr.fedorainfracloud.org/coprs/music/abseil-cpp/packages/
>> _______________________________________________
>> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
>> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
>> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>>
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux