Closed DS-Serafin closed 2 years ago
Likely the usual issue related to C++ standard and incoherency in the way abseil was built and consumed. Does it work if you try to force compiler.cppstd to 17?
might be relevant: https://github.com/conan-io/conan-center-index/pull/7443
@SpaceIm yes I can build with compiler.cppstd=17
but not sure this is a solution.
Didn't have the time to experiment, but I've proposed a solution in abseil recipe: https://github.com/conan-io/conan-center-index/pull/7443#issuecomment-1019947633
@SpaceIm I've tried to pin ABI according to your method in #9703
for abseil
test package it works like a charm, however, for google-cloud-cpp
it's getting tons of errors.
it seems like C++ standard is not properly propagated?
google-cloud-cpp.txt
Maybe because google-cloud-cpp forces C++11 instead of relying on cxx_std_11 feature? https://github.com/googleapis/google-cloud-cpp/blob/8e39dd5c711c3209da4273fa554a705eba82f53c/CMakeLists.txt#L31-L41
Maybe because google-cloud-cpp forces C++11 instead of relying on cxx_std_11 feature?
maybe. how should we deal with it in context of recipe(s)? reject other configurations besides C++11?
I would say fix google-cloud-cpp
CMakeLists to use cxx_std_11
feature for all its targets. Might not be straightforward since it's not something you can globally enable like CMAKE_CXX_STANDARD.
The issue I'm suspecting is the last sentence of https://github.com/conan-io/conan-center-index/pull/7443#issuecomment-1019947633:
Therefore, even if abseil was compiled with C++11 standard, a recipe using C++17 at consume time would not be tricked by going into the wrong branch (the opposite would not work, abseil compiled with C++17 could not work in a project forcing C++11, but in conan it shouldn't happen).
so:
compiler.cppstd
not set in profilecxx_std_11
feature and enables for example C++17google-cloud-cpp
forces C++11 => compile error, stuff like std::any
doesn't exist in C++11I would say fix
google-cloud-cpp
CMakeLists to usecxx_std_11
feature for all its targets.
but shouldn't it transitively receive cxx_std_11
whenever it does target_link_libraries(google-cloud-whatever PRIVATE absl::whatever)
?
It should, but conan generators are not able to emulate cmake features like cxx_std_11. And even with that, CXX_STANDARD in google-cloud-cpp defeats cxx features.
commenting this line: https://github.com/conan-io/conan-center-index/blob/master/recipes/google-cloud-cpp/all/conanfile.py#L110
causes google-cloud-cpp
build to pass for GCC11
still, not sure what's the best solution to propagate cxx_std_11
from abseil
.
if it's not supported by conan generator, maybe build modules may help?
otherwise, probably only calling set_target_properties
in CMakeLists.txt
(wrapper) could help.
still, the proper value for cxx_std_<year>
has to be obtained from somewhere, it means abseil
recipe has to store it somewhere (in package_info
or .json file in package?)
I think I'll fight with this issue here: https://github.com/conan-io/conan-center-index/pull/10499 Wish me luck! 😅
In abseil
sources I see they add cxx_std_11
target compile feature to all the targets: https://github.com/abseil/abseil-cpp/blob/master/CMake/AbseilHelpers.cmake#L263 (we force ABSL_PROPAGATE_CXX_STD=True
).
On GCP we are forcing C++11 (CMAKE_CXX_STANDARD
) https://github.com/conan-io/conan-center-index/blob/master/recipes/google-cloud-cpp/all/conanfile.py#L103 , but it has started to fail as I checked in this PR: https://github.com/conan-io/conan-center-index/pull/10498.
I'm not talking about new versions, but I would have expected that combination to work. Althoug cxx_std_11
is not propagated (Conan doesn't do that kind of stuff), the CMAKE_CXX_STANDARD
should apply to all targets while building google-cloud-cpp
libraries. It should be high enough...
I'm sure I'm missing something, I need to read more.
Oh... and we have grpc
in the middle (also requiring abseil
) that forces C++11: https://github.com/conan-io/conan-center-index/blob/master/recipes/grpc/all/conanfile.py#L160
Having a look at abseil
sources I found this file: https://github.com/abseil/abseil-cpp/blob/ac1398a6296de03413d7b88df4b4aa16e9e450cc/absl/base/options.h, which we are modifying in abseil
recipe. It has some very interesting content:
// ABSL_OPTION_USE_STD_STRING_VIEW
//
// This option controls whether absl::string_view is implemented as an alias to
// std::string_view, or as an independent implementation.
//
// A value of 0 means to use Abseil's implementation. This requires only C++11
// support, and is expected to work on every toolchain we support.
//
// 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.
//
// 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.
//
// User code should not inspect this macro. To check in the preprocessor if
// absl::string_view is a typedef of std::string_view, use the feature macro
// ABSL_USES_STD_STRING_VIEW.
#define ABSL_OPTION_USE_STD_STRING_VIEW 2
My Conan package (GCC 11) has value 1, so consumers require C++17...
So, even if abseil
uses target_compile_features($abseil_stuff PUBLIC cxx_std_11)
, it detects that the compiler is able to use some newer features and the API will require C++17. Am I right?
The problem here is that we should be able to propagate downstream the minimal requirement (after parsing this options.h
file!!!) to the consumers:
abseil
itself and create something that would be automatically consumed (like some build-module) and warns/raises the consumer if the standard is not high enoughI'm proposing these changes to abseil
, that way the recipe will propagate (via Conan targets) the required C++ standard to its consumers: https://github.com/conan-io/conan-center-index/pull/10502. I have tested it using GCC11 and GCC8 and it works when building the dependency chain abseil
, grpc
and google-cloud-cpp
(see all changes together here: https://github.com/conan-io/conan-center-index/pull/10499).
The problem here is that we should be able to propagate downstream the minimal requirement (after parsing this options.h file!!!) to the consumers:
Itis not a minimal requirement. It is cppstd==17. And I think that is a bug. You also cant compile with cpp20
Edit: I think it is cppstd == default cppstd of that compiler
I've tested it using docker image conanio/gcc11-ubuntu16.04:1.47.0
and my changes in #10499.
-s compiler.cppstd=20
If using GCC11, in my proposal, the abseil
targets have a target_compiler_features(<abseil-thin> INTERFACE cxx_std_17)
so consumers will use C++17. This minimal requirement is propagated downstream. For older compilers it propagates cxx_std_11
, and if C++20 is forced (compiler.cppstd=20
), then it will use that C++ standard to build all the libraries.
Edit.- Only tested latest version 1.39.1
Package and Environment Details (include every applicable attribute)
Conan profile
The toolchain only contains some definitions for gcc-11 and does not really matter it will also break with a default gcc 11 build.
Steps to reproduce (Include if Applicable)
Logs (Include/Attach if Applicable)
Click to expand log
``` /usr/bin/ld: ../../lib/libgoogle_cloud_cpp_generator.a(codegen_utils.cc.o): in function `google::cloud::generator_internal::CurrentCopyrightYear[abi:cxx11]()': codegen_utils.cc:(.text+0x125): undefined reference to `absl::lts_20211102::FormatTime[abi:cxx11](absl::lts_20211102::string_view, absl::lts_20211102::Time, absl::lts_20211102::TimeZone)' /usr/bin/ld: ../../lib/libgoogle_cloud_cpp_generator.a(codegen_utils.cc.o): in function `google::cloud::generator_internal::ProtoNameToCppName[abi:cxx11](absl::lts_20211102::string_view)': codegen_utils.cc:(.text+0x31e): undefined reference to `absl::lts_20211102::StrReplaceAll[abi:cxx11](absl::lts_20211102::string_view, std::initializer_list