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.
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.
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
