bazel: wrong link order of system libraries in cc rules
Description of the problem / feature request:
protoc (protobuf v3.8.0 and v3.9.1) build fails with bazel 0.27.1, 0.28.1, 0.29.1 and 1.0.0 on centos 7 with devtoolset-{7,8}. We don’t have any CROSSTOOL defined
bazel 0.26.1 works with no issues
Bugs: what’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
$ bazel build @com_google_protobuf//:protoc
.....
Execution platform: @bazel_tools//platforms:host_platform
bazel-out/k8-fastbuild/bin/external/com_google_protobuf/_objs/protoc_lib/command_line_interface.pic.o:command_line_interface.cc:function google::protobuf::compiler::CommandLineInterface::ExpandArgumentFile(std::string const&, std::vector<std::string, std::allocator<std::string> >*): error: undefined reference to 'std::basic_ios<char, std::char_traits<char> >::operator bool() const'
bazel-out/k8-fastbuild/bin/external/com_google_protobuf/_objs/protoc_lib/java_helpers.pic.o:java_helpers.cc:function google::protobuf::compiler::java::SortFieldsByNumber(google::protobuf::Descriptor const*): error: undefined reference to '__cxa_throw_bad_array_new_length'
bazel-out/k8-fastbuild/bin/external/com_google_protobuf/_objs/protoc_lib/objectivec_message.pic.o:objectivec_message.cc:function google::protobuf::compiler::objectivec::(anonymous namespace)::SortFieldsByNumber(google::protobuf::Descriptor const*): error: undefined reference to '__cxa_throw_bad_array_new_length'
bazel-out/k8-fastbuild/bin/external/com_google_protobuf/_objs/protoc_lib/objectivec_message.pic.o:objectivec_message.cc:function google::protobuf::compiler::objectivec::(anonymous namespace)::SortFieldsByStorageSize(google::protobuf::Descriptor const*): error: undefined reference to '__cxa_throw_bad_array_new_length'
bazel-out/k8-fastbuild/bin/external/com_google_protobuf/_objs/protobuf/dynamic_message.pic.o:dynamic_message.cc:function google::protobuf::DynamicMessageFactory::GetPrototypeNoLock(google::protobuf::Descriptor const*): error: undefined reference to '__cxa_throw_bad_array_new_length'
collect2: error: ld returned 1 exit status
What operating system are you running Bazel on?
Centos 7
What’s the output of bazel info release?
release 1.0.0 (also tried 0.29.1, 0.28.1 and 0.27.1)
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 31 (14 by maintainers)
Commits related to this issue
- Update Jaxlib docker build. * work around https://github.com/bazelbuild/bazel/issues/9254 by setting BAZEL_LINKLIBS=-lstdc++ * drop CUDA 9.0 support, since we use a batched kernel only present in CUD... — committed to hawkinsp/jax by hawkinsp 4 years ago
- C++: Move default linker flags with libs after libraries Default linker flags contains flags like -lstdc++ which should come after the user libraries. The library flags are removed from default linke... — committed to bazelbuild/bazel by oquenchil 4 years ago
Re: bazel 1.2.0 build from dist source Thank goodness I found this issue and read Alex’s identification to
bazel/tools/cpp/unix_cc_configure.bzl. I was able to build bazel from dist after running into this exact same issue by changingbazel/tools/cpp/unix_cc_configure.bzlline 379 from the empty string""to"-lstdc++". Look for the assignmentlink_libs =. Hopefully this is the end of this C++ toolchain nonsense. I’ll be using Bazel with Golang (Golang is trivial to install) which avoids all of C/C++ complexities.adding proper toolchain definition fixes the issue, plz check my sample repo
https://github.com/ali5h/bazel_devtoolset
Hey, I don’t know much about CentOS and devtoolset-8, can you please give me step by step command-lines how to reproduce this using a fresh CentOS 7 VM or using Docker?
We don’t test that on our CI, if I can reproduce maybe I can see which changes are necessary on the toolchain.
Thanks!