New issue
Advanced search Search tips

Issue 748474 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Sep 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug

Blocked on:
issue 748476

Blocking:
issue 724628
issue 747030



Sign in to add a comment

dev-libs/grpc uses both clang and g++ for compilation

Project Member Reported by manojgupta@chromium.org, Jul 25 2017

Issue description

Discovered when testing libc++ as the stdlib.

https://uberchromegw.corp.google.com/i/chromiumos.tryserver/builders/chromiumos-sdk/builds/2410

grpc-1.3.0: x86_64-pc-linux-gnu-g++ -std=c++11 -I. -Iinclude -I/var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/gens -DNDEBUG -DINSTALL_PREFIX=\"/usr\" -g -Wall -Wextra -Werror -Wno-long-long -Wno-unused-parameter -DOSATOMIC_USE_INLINED=1 -fPIC -MMD -MF /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/objs/opt/src/compiler/ruby_generator.dep -c -o /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/objs/opt/src/compiler/ruby_generator.o src/compiler/ruby_generator.cc
grpc-1.3.0: mkdir -p `dirname /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/objs/opt/src/cpp/client/cronet_credentials.o`
grpc-1.3.0: mkdir -p `dirname /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/objs/opt/src/cpp/common/insecure_create_auth_context.o`
grpc-1.3.0: x86_64-pc-linux-gnu-clang++ -pthread  -Ithird_party/googletest/googletest/include  -g -Wall -Wextra -Werror -Wno-long-long -Wno-unused-parameter -DOSATOMIC_USE_INLINED=1 -O2 -fPIC -I. -Iinclude -I/var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/gens -DNDEBUG -DINSTALL_PREFIX=\"/usr\"     -DTSI_OPENSSL_ALPN_SUPPORT=0 -O2 -pipe -std=c++11   -MMD -MF /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/objs/opt/src/cpp/client/cronet_credentials.dep -c -o /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/objs/opt/src/cpp/client/cronet_credentials.o src/cpp/client/cronet_credentials.cc

Because of the mixed compilation, the build fails at linking when libc++ is used as the stdlib in clang. Making this package use libstdlibc++ is not an option since it will require dev-libs/protobuf to use libstdc++. And that will force many other packages to be forced to libstdc++ as well.

grpc-1.3.0: x86_64-pc-linux-gnu-g++ -g -fPIC -Llibs/opt /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/objs/opt/src/compiler/objective_c_plugin.o /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/libs/opt/libgrpc_plugin_support.a  -lprotoc -lprotobuf -lprotoc -lprotoc -lprotobuf -o /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/bins/opt/grpc_objective_c_plugin
grpc-1.3.0: /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/objs/opt/src/compiler/csharp_plugin.o: In function `ParseGeneratorParameter':
grpc-1.3.0: /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/./src/compiler/config.h:87: undefined reference to `google::protobuf::compiler::ParseGeneratorParameter(std::string const&, std::vector<std::pair<std::string, std::string>, std::allocator<std::pair<std::string, std::string> > >*)'
grpc-1.3.0: /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/objs/opt/src/compiler/csharp_plugin.o:(.data.rel.ro._ZTV19CSharpGrpcGenerator[_ZTV19CSharpGrpcGenerator]+0x28): undefined reference to `google::protobuf::compiler::CodeGenerator::GenerateAll(std::vector<google::protobuf::FileDescriptor const*, std::allocator<google::protobuf::FileDescriptor const*> > const&, std::string const&, google::protobuf::compiler::GeneratorContext*, std::string*) const'
grpc-1.3.0: /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/libs/opt/libgrpc_plugin_support.a(csharp_generator.o): In function `GenerateDocCommentBodyImpl':
grpc-1.3.0: /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/src/compiler/csharp_generator.cc:110: undefined reference to `google::protobuf::io::Printer::Print(char const*, char const*, std::string const&)'
grpc-1.3.0: /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/libs/opt/libgrpc_plugin_support.a(csharp_generator.o): In function `GenerateMarshallerFields':
grpc-1.3.0: /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/src/compiler/csharp_generator.cc:336: undefined reference to `google::protobuf::io::Printer::Print(char const*, char const*, std::string const&, char const*, std::string const&)'
grpc-1.3.0: /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/libs/opt/libgrpc_plugin_support.a(csharp_generator.o): In function `GenerateStaticMethodField':
grpc-1.3.0: /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/src/compiler/csharp_generator.cc:347: undefined reference to `google::protobuf::io::Printer::Print(char const*, char const*, std::string const&, char const*, std::string const&, char const*, std::string const&)'
grpc-1.3.0: /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/src/compiler/csharp_generator.cc:351: undefined reference to `google::protobuf::io::Printer::Print(char const*, char const*, std::string const&)'
grpc-1.3.0: /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/src/compiler/csharp_generator.cc:353: undefined reference to `google::protobuf::io::Printer::Print(char const*, char const*, std::string const&)'
grpc-1.3.0: /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/src/compiler/csharp_generator.cc:354: undefined reference to `google::protobuf::io::Printer::Print(char const*, char const*, std::string const&)'
grpc-1.3.0: /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/src/compiler/csharp_generator.cc:356: undefined reference to `google::protobuf::io::Printer::Print(char const*, char const*, std::string const&)'
grpc-1.3.0: /var/tmp/portage/dev-libs/grpc-1.3.0/work/grpc-1.3.0/src/compiler/csharp_generator.cc:358: undefined reference to `google::protobuf::io::Printer::Print(char const*, char const*, std::string const&)'

The build needs to be fixed so that it uses clang everywhere if CC is clang.

 
Most likely it is because of setting HOSTCC as tc-getBUILD-CC which will always return gcc. 

Comment 2 by vapier@chromium.org, Jul 25 2017

Cc: vapier@chromium.org
the mixing of compilers isn't a problem ... it builds tools for compile-time only.  there might be mixing of flags between the build & host toolchains though.
Yes as Mike said, grpc builds protoc plugins that it then uses to generate code that gets compiled into a library.  I reported this upstream but they said they are not interested in trying to maintain backwards compatibility with older plugins so they don't want to provide a way for users to tell the build to use the system plugins (even though in our case they are identical).
Blocking: 747030
Blockedon: 748476
Status: WontFix (was: Untriaged)
Will fix tc-getBUILD-CC to use clang.

Sign in to add a comment