-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Comments
Is there a workaround for this? |
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. |
not 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 "no stalebot" or other activity occurs. Thank you for your contributions. |
The linked bazel issue for this has a fix merged. Is this good in envoy now? |
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 |
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]>
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
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]>
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]>
Description:
When building envoy with
--config=libc++
, clang will fail to find standard C++ headers.Repro steps:
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++.
The text was updated successfully, but these errors were encountered: