On Thu, 16 Mar 2023 at 00:34, Ben Beasley wrote:
Thank you for helping dig into the details. What you’ve written makes sense, and is consistent with the comments in absl/base/options.h regarding ABSL_OPTION_USE_STD_STRING_VIEW:
A value of 2 means to detect the C++ version being used to compile Abseil,
and use an alias only if a working std::string_view is available. This
option is useful when you are building your program from source. It should
not be used otherwise -- for example, if you are distributing Abseil in a
binary package manager -- since in mode 2, absl::string_view will name a
different type, with a different mangled name and binary layout, depending on
the compiler flags passed by the end user. For more info, see
https://abseil.io/about/design/dropin-types.
For completeness, the reason the value of ABSL_OPTION_USE_STD_STRING_VIEW changed from 2 to 1 since the previous release is an intentional upstream change described as follows:
Change `absl/base/options.h` at install time to reflect the ABI used
to compile the libraries, i.e., if Abseil was compiled with
C++ >= 17 then the `ABSL_OPTION_USE_STD_*` macros are set to `1`,
because then the C++ 17 types are embedded in the ABI of the installed
artifacts.
Likewise, set the `target_compile_features()` of Abseil libraries
to reflect the C++ version used to compile them. If they the Abseil
libraries are compiled with C++ >= 17, then all downstream
dependencies must also be compiled with C++ >= 17.
So the only way that dependent packages can use C++14 is if we intentionally and explicitly downgrade the C++ standard used to compile abseil-cpp from C++17 (the default) to C++14.
Given all this, it appears to me that the best course is still to keep abseil-cpp on the default C++17 standard and accept that dependent packages cannot use C++14. However, I’m pleased to have a much better understanding of what is happening, how, and why, and I’m still happy to consider any proposals to proceed differently.
Agreed. We know why it's needed now, and so can explain it to any maintainers of packages that need to move to C++17. Thanks for humouring my curiosity about it!
On 3/15/23 6:29 PM, Jonathan Wakely wrote:
On Wed, 15 Mar 2023 at 22:17, Jonathan Wakely <jwakely@xxxxxxxxxx> wrote:
On Wed, 15 Mar 2023 at 22:14, Ben Beasley <code@xxxxxxxxxxxxxxxxxx> wrote:
Thank you for prompting me to look at this more closely. A quick investigation reveals:
“Abseil libraries require C++14 as the current minimum standard. When compiled with C++17 (either because it is the compiler's default or explicitly requested), then Abseil requires C++17.”
https://github.com/abseil/abseil-cpp/blob/20230125.1/CMake/AbseilHelpers.cmake#L291
The abseil-cpp package in Fedora has been compiled as C++17 for some time—at first explicitly, but this would also now be the default if the spec file did not configure a particular standard—so it seems dependent packages already technically needed C++17, and it is mere happenstance that this particular release is revealing incompatibilities.
I'm not sure if that's true, see my other email which crossed with yours. In the previous release absl::string_view would work for both C++14 and C++17, because USE_STD_STRING_VIEW was defined to 2, so adapted to the headers that included it.
In the new release it is hardcoded to only work for C++17. That seems like a new change in the new version, not something that was already present.
Digging deeper, maybe it was true, and ilbc was just getting away with it by chance.
Several member functions of absl::string_view are defined out-of-line in abseil-cpp-20220623.1/absl/strings/string_view.cc but if the library is built as C++17 then those won't be defined (because absl::string_view is just an alias for std::string_view, so all the members come from libstdc++). So all clients of abseil-cpp shared libs do need to be compiled as C++17 or later. It looks like libilbc.so.3.0.4 doesn't actually use any libasbl_*.so libs, so only uses libabsl headers, and that's why it "worked" when the header was adaptive w.r.t. the string-view definition. It doesn't care that there are no definitions for those string_view member functions, because it happens to not use those specific member functions.
_______________________________________________ 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
