protoc with Non-standard Compiler Toolchain

[llchan]

In the docs, it says it's possible to use a non-standard compiler by specifying CC/LD_LIBRARY_PATH. However, this seems to break host tools:

bazel-out/host/bin/external/com_google_protobuf/protoc: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by bazel-out/host/bin/external/com_google_protobuf/protoc)
bazel-out/host/bin/external/com_google_protobuf/protoc: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by bazel-out/host/bin/external/com_google_protobuf/protoc)
bazel-out/host/bin/external/com_google_protobuf/protoc: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by bazel-out/host/bin/external/com_google_protobuf/protoc)

Running bazel with -s, it seems that protoc is compiled with the non-standard compiler but executed in a exec env - environment without the matching LD_LIBRARY_PATH. I don't have a preference which toolchain it uses, but build/execution should match.

This is basically the same issue as #4736, but if I'm reading this right the resolution there was to modify the bazel source code to pass in a custom environment, which isn't really a reasonable solution. My previous hack involved several patches to cc_configure.bzl and cc_wrapper.py, but now that those are gone it's less clear to me how to get this to work.

I believe this should be reproducible in any system with gcc<7, with a gcc>=7 available in a non-system path.

[lizan]

@llchan can you provide more context of your environment?

Try passing --action_env=LD_LIBRARY_PATH, that will propagate LD_LIBRARY_PATH when bazel executes the specified compiler.

[llchan]

I'm running on RHEL 7.5 with system gcc 4.8.5. Envoy requires a newer gcc, so I have a gcc 8.3.0 built in a separate path.

When building, I set CC/LD_LIBRARY_PATH in the shell that's calling bazel, and that seems to be respected. I've tried it with/without --action_env, but either way the protoc call is invoked with an empty environment. I also tried various things like LDFLAGS=-static-libgcc -static-libstdc++, but this does not seem to be passed into the protoc link step.

[llchan]

Actually this could be related to bazelbuild/bazel#4008. If that is the case, what's the best workaround? I no longer have the cc_wrapper to hijack LDFLAGS the way I used to.

[lizan]

@llchan try pass those LDFLAGS via --host_linkopt, i.e. --host_linkopt=-static-libgcc --host_linkopt=-static-libstdc++.

[llchan]

That worked, thanks for the tip!

We should probably still fix the mismatch between host tool compiler and host tool execution env. Seems like CC is respected but LD_LIBRARY_PATH is not. If it's any easier, I think it's acceptable for now to make host tools compile with the system compiler and not make that overridable.

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted". Thank you for your contributions.