Philipp Schrader

@gregestren , FYI in case it's interesting. I suspect it's got nothing to do with incompatible target skipping. I'm not sure what the cause might be.

Interesting! With `--keep_going` the dependency chain explanation disappears completely: ```console $ bazel --nohome_rc build //:target1 --keep_going 2022/05/09 21:42:29 Using unreleased version at commit 4ff441b13db6b6f5d5d317881c6383f510709b19 WARNING: The following rc files are...

After bisecting, it looks like this issue was introduced in e8a99923af0a017e68afa3007eff01229df54f81 (https://bazel-review.googlesource.com/c/bazel/+/196876). @joeleba , would you happen to know what might be causing this? I haven't looked into it yet,...

Definitely not blocking anything. Just something I am hoping to resolve before bazel 6. I am hoping to investigate a potential solution in the next few weeks.

@joeleba , I pushed #16178 for your consideration.

To clarify, I think that a _directly_ incompatible target should be allowed to depend on private targets without error. The point here is that directly incompatible targets don't have their...

Yes, that's correct. Does that sound reasonable?

Any thoughts from the Abseil team on this? tensorflow appears to pull this in. That means it clashes with gperftools which also provides the same symbols.

Thanks @derekmauro. I renamed the gperftools symbols and it appears to work fine now.

Here's what I did: ```patch diff --git a/third_party/gperftools/src/base/dynamic_annotations.c b/third_party/gperftools/src/base/dynamic_annotations.c index 87bd2ecde9..1b3cbff8cd 100644 --- a/third_party/gperftools/src/base/dynamic_annotations.c +++ b/third_party/gperftools/src/base/dynamic_annotations.c @@ -149,7 +149,7 @@ static int GetRunningOnValgrind(void) { } /* See the comments in...