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