Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

the libc++ build configuration does not work on recent clang versions #16608

Closed
jpeach opened this issue May 21, 2021 · 6 comments · Fixed by #19760
Closed

the libc++ build configuration does not work on recent clang versions #16608

jpeach opened this issue May 21, 2021 · 6 comments · Fixed by #19760
Labels
area/build investigate Potential bug that needs verification

Comments

@jpeach
Copy link
Contributor

jpeach commented May 21, 2021

Description:

When building envoy with --config=libc++, clang will fail to find standard C++ headers.

Repro steps:

$ CC=clang CXX=clang bazel build --config=clang --config=libc++ //source/exe:envoy-static
...
Use --sandbox_debug to see verbose messages from the sandbox clang failed: error executing command 
  (cd /home/jpeach/.cache/bazel/_bazel_jpeach/af5610e61ef13740f13f753f9b95f927/sandbox/linux-sandbox/94/execroot/envoy && \
  exec env - \
    PATH=/bin:/usr/bin:/usr/local/bin \
    PWD=/proc/self/cwd \
  /usr/bin/clang -U_FORTIFY_SOURCE -fstack-protector -Wall -Wthread-safety -Wself-assign -Wno-free-nonheap-object -fcolor-diagnostics -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections -fdata-sections '-stdlib=libc++' -MD -MF bazel-out/host/bin/external/com_google_protobuf/_objs/protoc/main.d '-frandom-seed=bazel-out/host/bin/external/com_google_protobuf/_objs/protoc/main.o' -iquote external/com_google_protobuf -iquote bazel-out/host/bin/external/com_google_protobuf -iquote external/bazel_tools -iquote bazel-out/host/bin/external/bazel_tools -isystem external/com_google_protobuf/src -isystem bazel-out/host/bin/external/com_google_protobuf/src -isystem bazel-out/host/bin/external/envoy/bazel/foreign_cc/zlib/include -g0 -g0 -no-canonical-prefixes -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -c external/com_google_protobuf/src/google/protobuf/compiler/main.cc -o bazel-out/host/bin/external/com_google_protobuf/_objs/protoc/main.o)
Execution platform: @local_config_platform//:host

Use --sandbox_debug to see verbose messages from the sandbox
In file included from external/com_google_protobuf/src/google/protobuf/compiler/main.cc:31:
external/com_google_protobuf/src/google/protobuf/compiler/cpp/cpp_generator.h:40:10: fatal error: 'string' file not found
#include <string>
         ^~~~~~~~
1 error generated.
Target //source/exe:envoy-static failed to build

The problem seems to be that bazel adds the -no-canonical-prefixes flag to clang, which breaks the built-in search path behavior.

This is bazelbuild/bazel#13071. Filing the corresponding bug here to help future people trying to build envoy with libc++.

@jpeach jpeach added bug triage Issue requires triage labels May 21, 2021
@alyssawilk alyssawilk added area/build investigate Potential bug that needs verification and removed bug triage Issue requires triage labels May 24, 2021
@howardjohn
Copy link
Contributor

Is there a workaround for this?

@github-actions
Copy link

github-actions bot commented Jul 7, 2021

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 "no stalebot" or other activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale stalebot believes this issue/PR has not been touched recently label Jul 7, 2021
@jpeach
Copy link
Contributor Author

jpeach commented Jul 7, 2021

not stale

@phlax phlax added no stalebot Disables stalebot from closing an issue and removed stale stalebot believes this issue/PR has not been touched recently labels Jul 7, 2021
@mattklein123 mattklein123 removed the no stalebot Disables stalebot from closing an issue label Mar 22, 2022
@github-actions
Copy link

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 "no stalebot" or other activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale stalebot believes this issue/PR has not been touched recently label Apr 21, 2022
@keith
Copy link
Member

keith commented Apr 22, 2022

The linked bazel issue for this has a fix merged. Is this good in envoy now?

@keith
Copy link
Member

keith commented Apr 22, 2022

Actually this never was updated in rules_cc, just bazel (as usual). Which is partially why I'm working on #19760, so I bet it's not fixed

@github-actions github-actions bot removed the stale stalebot believes this issue/PR has not been touched recently label Apr 22, 2022
keith added a commit that referenced this issue Apr 27, 2022
The plans for bazel to move to rules_cc have been postponed without any
communication. There's no value to us in using this right now, but it
will be trivial to re-adopt in the future if needed. But it has the
downside of using a fork of bazel's crosstool, that has to be updated
independently of bazel, which doesn't always happen as improvements are
made.

More details: bazelbuild/rules_cc#86 bazelbuild/bazel#14150

This also required a `--host_action_env` addition to mirror the variables we
pass through to actions in general. This is required because C++ toolchain
setup which discovers linkers in the cc configuration which uses PATH directly,
but then host actions didn't use PATH because of
--incompatible_strict_action_env, so gcc couldn't discover the path of lld even
though `-fuse-ld=lld` was passed.

Fixes #16608

Signed-off-by: Keith Smiley <[email protected]>
lizan pushed a commit to envoyproxy/data-plane-api that referenced this issue Apr 27, 2022
The plans for bazel to move to rules_cc have been postponed without any
communication. There's no value to us in using this right now, but it
will be trivial to re-adopt in the future if needed. But it has the
downside of using a fork of bazel's crosstool, that has to be updated
independently of bazel, which doesn't always happen as improvements are
made.

More details: bazelbuild/rules_cc#86 bazelbuild/bazel#14150

This also required a `--host_action_env` addition to mirror the variables we
pass through to actions in general. This is required because C++ toolchain
setup which discovers linkers in the cc configuration which uses PATH directly,
but then host actions didn't use PATH because of
--incompatible_strict_action_env, so gcc couldn't discover the path of lld even
though `-fuse-ld=lld` was passed.

Fixes envoyproxy/envoy#16608

Signed-off-by: Keith Smiley <[email protected]>

Mirrored from https://github.com/envoyproxy/envoy @ 1edd65f80bd8ded5cb2c0ebeec818784ebd76bfb
ravenblackx pushed a commit to ravenblackx/envoy that referenced this issue Jun 8, 2022
The plans for bazel to move to rules_cc have been postponed without any
communication. There's no value to us in using this right now, but it
will be trivial to re-adopt in the future if needed. But it has the
downside of using a fork of bazel's crosstool, that has to be updated
independently of bazel, which doesn't always happen as improvements are
made.

More details: bazelbuild/rules_cc#86 bazelbuild/bazel#14150

This also required a `--host_action_env` addition to mirror the variables we
pass through to actions in general. This is required because C++ toolchain
setup which discovers linkers in the cc configuration which uses PATH directly,
but then host actions didn't use PATH because of
--incompatible_strict_action_env, so gcc couldn't discover the path of lld even
though `-fuse-ld=lld` was passed.

Fixes envoyproxy#16608

Signed-off-by: Keith Smiley <[email protected]>
oschaaf pushed a commit to maistra/envoy that referenced this issue Oct 26, 2022
The plans for bazel to move to rules_cc have been postponed without any
communication. There's no value to us in using this right now, but it
will be trivial to re-adopt in the future if needed. But it has the
downside of using a fork of bazel's crosstool, that has to be updated
independently of bazel, which doesn't always happen as improvements are
made.

More details: bazelbuild/rules_cc#86 bazelbuild/bazel#14150

This also required a `--host_action_env` addition to mirror the variables we
pass through to actions in general. This is required because C++ toolchain
setup which discovers linkers in the cc configuration which uses PATH directly,
but then host actions didn't use PATH because of
--incompatible_strict_action_env, so gcc couldn't discover the path of lld even
though `-fuse-ld=lld` was passed.

Fixes envoyproxy/envoy#16608

Signed-off-by: Keith Smiley <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/build investigate Potential bug that needs verification
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants