1

We were using grpc 1.15.0 for long time and linked to application compiled with C++11. We try to upgrade grpc to 1.46.5 (base on documentation gRPC C++ 1.46 will be the last release supporting C++11)

I had simple test program that only calls

std::shared_ptr<grpc::Channel> channel = grpc::CreateChannel("https://127.0.0.1:9999", ssl_creds);

With 1.15.0 it was compiled without any errors

g++ adam_test1.cpp -std=c++11 -I/home/adam/grpc1.15.0/obj/linux_x86-64/3rd/include -L/home/adam/grpc1.15.0/obj/linux_x86-64/3rd/lib64 -l:libgrpc++.a -l:libgrpc.a -l:libgpr.a -l:libaddress_sorting.a -lcrypto -lssl -lcares -lz  -pthread -o adam_test1

The same with 1.46.5 show many undefined reference.

Tried even add some libabsl but still failing

g++ adam_test1.cpp -std=c++11 -I/home/adam/grpc1.46.5/obj/linux_x86-64/3rd/include -L/usr/lib64 -L/home/adam/grpc1.46.6/obj/linux_x86-64/3rd/lib64 -l:libgrpc++.a -l:libgrpc.a -l:libgpr.a -l:libaddress_sorting.a -l:libabsl_base.a -l:libabsl_cord.a -l:libabsl_status.a -l:libabsl_strings.a  -l:libabsl_synchronization.a  -lcrypto -lssl -lcares -lz  -pthread -lstdc++ -o adam_test2

some logs

    /home/adam/grpc1.46.5/obj/linux_x86-64/3rd/lib64/libgrpc.a(client_channel.cc.o): In function `grpc_core::ClientChannel::CreateOrUpdateLbPolicyLocked(grpc_core::RefCountedPtr<grpc_core::LoadBalancingPolicy::Config>, absl::lts_20211102::optional<std::string> const&, grpc_core::Resolver::Result)':
client_channel.cc:(.text+0x8c01): undefined reference to `absl::lts_20211102::internal_statusor::Helper::HandleInvalidStatusCtorArg(absl::lts_20211102::Status*)'
/home/adam/grpc1.46.5/obj/linux_x86-64/3rd/lib64/libgrpc.a(client_channel.cc.o): In function `std::_Function_handler<void (), grpc_core::ClientChannel::SubchannelWrapper::WatcherWrapper::OnConnectivityStateChange()::{lambda()#1}>::_M_invoke(std::_Any_data const&)':
client_channel.cc:(.text._ZNSt17_Function_handlerIFvvEZN9grpc_core13ClientChannel17SubchannelWrapper14WatcherWrapper25OnConnectivityStateChangeEvEUlvE_E9_M_invokeERKSt9_Any_data[_ZNSt17_Function_handlerIFvvEZN9grpc_core13ClientChannel17SubchannelWrapper14WatcherWrapper25OnConnectivityStateChangeEvEUlvE_E9_M_invokeERKSt9_Any_data]+0x4ce): undefined reference to `absl::lts_20211102::optional_internal::throw_bad_optional_access()'
/home/adam/grpc1.46.5/obj/linux_x86-64/3rd/lib64/libgrpc.a(client_channel.cc.o): In function `absl::lts_20211102::StatusOr<absl::lts_20211102::InlinedVector<grpc_core::ServerAddress, 1ul, std::allocator<grpc_core::ServerAddress> > >::StatusOr()':
client_channel.cc:(.text._ZN4absl12lts_202111028StatusOrINS0_13InlinedVectorIN9grpc_core13ServerAddressELm1ESaIS4_EEEEC2Ev[_ZN4absl12lts_202111028StatusOrINS0_13InlinedVectorIN9grpc_core13ServerAddressELm1ESaIS4_EEEEC5Ev]+0x44): undefined reference to `absl::lts_20211102::internal_statusor::Helper::HandleInvalidStatusCtorArg(absl::lts_20211102::Status*)'
/home/adam/grpc1.46.5/obj/linux_x86-64/3rd/lib64/libgrpc.a(lb_policy.cc.o): In function `grpc_core::LoadBalancingPolicy::UpdateArgs::operator=(grpc_core::LoadBalancingPolicy::UpdateArgs&&)':
lb_policy.cc:(.text+0x69e): undefined reference to `absl::lts_20211102::internal_statusor::Helper::HandleInvalidStatusCtorArg(absl::lts_20211102::Status*)'
/home/adam/grpc1.46.5/obj/linux_x86-64/3rd/lib64/libgrpc.a(lb_policy.cc.o): In function `grpc_core::LoadBalancingPolicy::UpdateArgs::operator=(grpc_core::LoadBalancingPolicy::UpdateArgs const&)':
lb_policy.cc:(.text+0x9ac): undefined reference to `absl::lts_20211102::internal_statusor::Helper::HandleInvalidStatusCtorArg(absl::lts_20211102::Status*)'
/home/adam/grpc1.46.5/obj/linux_x86-64/3rd/lib64/libgrpc.a(lb_policy_registry.cc.o): In function `grpc_core::LoadBalancingPolicyRegistry::ParseLoadBalancingConfig(grpc_core::Json const&, grpc_error**)':

The grpc and absl are also compiled with -std=c++11. What should be the correct cmake command to build libgrpc.a with C++11 and what other abls libs need to be linked when using it ?

git submodule update --init ${GRPC_SOURCE}/third_party/re2/ ${GRPC_SOURCE}/third_party/abseil-cpp/
# Install absl
mkdir -p "third_party/abseil-cpp/cmake/build"
pushd "third_party/abseil-cpp/cmake/build"
cmake -std=c++11 -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=${PROD_DIR} -DCMAKE_POSITION_INDEPENDENT_CODE=TRUE ../..
make -j4 install
popd

cmake \
    -std=c++11 \
    -DPKG_CONFIG_USE_CMAKE_PREFIX_PATH=1 \
    -DCMAKE_BUILD_TYPE=Release \
    -DgRPC_INSTALL=ON \
    -DgRPC_BUILD_TESTS=OFF \
    -DgRPC_CARES_PROVIDER=package \
    -DgRPC_ABSL_PROVIDER=package \
    -DgRPC_PROTOBUF_PROVIDER=package \
    -DgRPC_RE2_PROVIDER=package \
    -DgRPC_SSL_PROVIDER=package \
    -DgRPC_ZLIB_PROVIDER=package \
    -DgRPC_ABSL_PROVIDER=module \
    -DgRPC_INSTALL_SUPPORTED_FROM_MODULE=ON \
    -Dc-ares_DIR=${CARES_DIR}/lib/cmake/c-ares  \
    -DgRPC_INSTALL_LIBDIR=${SYS_LIB_DIR} \
    -D_gRPC_PROTOBUF_PROTOC=${PROTO_DIR} \
    -DCMAKE_PREFIX_PATH=${OPENSSL_DIR}\\;${PROTO_DIR}\\;${ZLIB_DIR} \
    -DCMAKE_EXE_LINKER_FLAGS="-Wl,-R/opt/3rd/lib64 -lprotoc  -lprotobuf" \
    -DCMAKE_INSTALL_PREFIX=${PROD_DIR} \
    -DCMAKE_CXX_FLAGS="-I${PROTO_DIR}/include -I${OPENSSL_DIR}/include -I./third_party/cares -L${PROTO_DIR}/lib -L${OPENSSL_DIR}/lib" \
    -DCMAKE_C_FLAGS="-I${PROTO_DIR}/include -I${OPENSSL_DIR}/include -L${PROTO_DIR}/lib -L${OPENSSL_DIR}/lib" \
    -LAH \
    ../..

make && make install 
  • To link with a library you provide the *library name*, not its file name. So to link with a library named `grpc++` you give the option `-lgrpc++`. – Some programmer dude Sep 27 '22 at 10:27
  • As for your problem, upgrading from version 1.15.0 to version 1.46.5 seems like a very big step. Have you tried to read the library documentation and changelog to see if there's something that has been removed from the library? Perhaps the functions mentioned in the errors have been obsoleted and then removed? – Some programmer dude Sep 27 '22 at 10:30
  • Although that would mean they should have been removed from the header files as well, and would have lead to other errors instead. Perhaps they were moved to other libraries? Again, what does the documentation say? – Some programmer dude Sep 27 '22 at 10:39
  • The problem was in linking libabsl in correct order. Had to add one by one. The second problem was old libstdc++ The libstdc++.so.6.0.19 did not had __cxa_throw_bad_array_new_length – user17259367 Sep 28 '22 at 12:46

1 Answers1

1

I was able to build after adding libabsl in correct order and also need to run on server with newer libstdc++.so that knows __cxa_throw_bad_array_length

g++ adam_test1.cpp -std=c++11 -I/home/adam/obj/linux_x86-64/3rd/include -L/usr/lib64 -L/home/adam/obj/linux_x86-64/3rd/lib64 -l:libgrpc++.a -l:libgrpc.a -l:libgpr.a -l:libaddress_sorting.a -l:libabsl_cord.a -l:libabsl_status.a -l:libabsl_strings.a  -l:libabsl_synchronization.a -l:libabsl_statusor.a -l:libabsl_bad_optional_access.a  -l:libabsl_bad_variant_access.a -l:libabsl_time.a -l:libabsl_time_zone.a -l:libabsl_throw_delegate.a -l:libabsl_hash.a  -l:libabsl_raw_logging_internal.a -l:libabsl_log_severity.a -l:libabsl_strings_internal.a -l:libabsl_malloc_internal.a -l:libre2.a -l:libupb.a -l:libabsl_base.a -l:libabsl_spinlock_wait.a -l:libabsl_symbolize.a -l:libabsl_str_format_internal.a -l:libabsl_random_internal_randen.a -l:libabsl_random_internal_randen_hwaes.a -l:libabsl_random_internal_randen_hwaes_impl.a -l:libabsl_random_internal_randen_slow.a -l:libabsl_random_internal_pool_urbg.a -l:libabsl_random_internal_platform.a -l:libabsl_random_internal_seed_material.a -l:libabsl_random_seed_gen_exception.a -l:libabsl_cord.a -l:libabsl_cord_internal.a -l:libabsl_cordz_functions.a -l:libabsl_cordz_info.a  -l:libabsl_int128.a -l:libabsl_demangle_internal.a -l:libabsl_stacktrace.a -l:libabsl_debugging_internal.a -l:libabsl_cordz_handle.a -l:libabsl_city.a -l:libabsl_low_level_hash.a -l:libabsl_exponential_biased.a -lcrypto -lssl -lcares -lz  -pthread -lstdc++ -o adam_test2

bash-4.4# nm -D  /usr/lib64/libstdc++.so.6.0.25 | grep throw_bad
00000000000c02c0 T _ZSt16__throw_bad_castv
00000000000c0280 T _ZSt17__throw_bad_allocv
00000000000c0300 T _ZSt18__throw_bad_typeidv
00000000000c0240 T _ZSt21__throw_bad_exceptionv
00000000000c0720 T _ZSt25__throw_bad_function_callv
00000000000949e0 T __cxa_throw_bad_array_length
00000000000954e0 T __cxa_throw_bad_array_new_length