-
Notifications
You must be signed in to change notification settings - Fork 3k
Description
We're using Abseil with our https://github.com/googleapis/google-cloud-cpp project. In order to support our CMake build, we compile and install Abseil in our docker images, so that our CMake builds can simply find and use the installed Abseil libraries. Here's how we compile and install Abseil in our docker images.
This has been working okay, until today, when we tried to use absl::StrSplit, which uses absl::string_view, and we got an error linking in our C++17 build (build log):
std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >)::{lambda(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)#13}::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const [clone .isra.0]':
storage_throughput_vs_cpu_benchmark.cc:(.text+0x2a48): undefined reference to `absl::lts_2020_02_25::ByChar::Find(std::basic_string_view<char, std::char_traits<char> >, unsigned long) const'
/usr/bin/ld: storage_throughput_vs_cpu_benchmark.cc:(.text+0x2c15): undefined reference to `absl::lts_2020_02_25::ByChar::Find(std::basic_string_view<char, std::char_traits<char> >, unsigned long) const'
collect2: error: ld returned 1 exit status
It looks like the problem is that ABSL_OPTION_USE_STD_STRING_VIEW defaults to 2 (link), which says to use std::string_view if >= C++17, otherwise use Abseil's custom absl::string_view. The issue is that we compile and install Abseil using some default compiler options (c++11 in this case), and we don't explicitly set ABSL_OPTION_USE_STD_STRING_VIEW. However ,when we link against the installed library in a C++17 build, we start using std::string_view, and then obviously the link fails.
Question: Are we holding it wrong? Have we installed Abseil wrong? Is there something we should be doing differently to solve this problem? We installed Abseil the way we thought we should, but I wouldn't be surprised if I did that wrong.
Some general thoughts about a solution
It seems like ABSL_OPTION_USE_STD_STRING_VIEW=2 is never the right thing for an installed Abseil. The installed binary artifacts were compiled with exactly one of Abseil's custom absl::string_view OR std::string, so having the installed base/options.h header default to choosing one of those doesn't seem right.
Could Abseil install a base/options.h that's configured w/ the options matching the way the binary artifacts were compiled/installed?
NOTE: In this issue I'm referring to absl::string_view, but the same issue will arise with absl::any, absl::optional, etc. So whatever solution we come up with here, should likely apply to all of those.
/cc: @coryan @derekmauro @vslashg