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.
https://github.com/abseil/abseil-cpp/blob/c8a2f92586fe9b4e1aff049108f5db8064924d8e/absl/base/options.h#L138
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.
https://github.com/abseil/abseil-cpp/commit/308bbf300fe9332130f4784c7a91fa2ad707d6e4
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 <jwak...@redhat.com> wrote:
On Wed, 15 Mar 2023 at 22:14, Ben Beasley
<c...@musicinmybrain.net> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
