Pedro

Aha, the remote cache bit is interesting too. @mattyclarkson did you have remote cache enabled too?

Are there two `cc_shared_libraries` linking `@proj//:proj_so`and the one that is a dependency is not exporting it? If so, then the error is intentional.

Just to clarify this was an intentional breaking change from 6.0 to 7.0. I see that `@proj//:proj_so` is a `cc_shared_library`, the rest of the error should tell which `cc_libraries` should...

Here on [the error](https://cs.opensource.google/bazel/bazel/+/master:src/main/starlark/builtins_bzl/common/cc/cc_shared_library.bzl;drc=2abc982ca5a8d1e829613629c8e3b44cf61b58c5;l=546) it says _If you are sure that the previous libraries are exported by the cc_shared_libraries_. Is this the case? If you look at the symbols exported...

Very likely that this must be fixed on the `cc_test` side, not `cc_shared_library`. The implementation already filters out the nodeps `*.so` that don't need to be linked, I don't remember...

If this affects `cc_test`, then it probably affects `cc_binary` with `linkstatic = 0`. The code path is the same, so fixing one should fix the other.

Can you post the error?

Not sure what's going on, I'd set a breakpoint (or print) here: https://cs.opensource.google/bazel/bazel/+/master:src/main/starlark/builtins_bzl/common/cc/cc_shared_library.bzl;drc=2abc982ca5a8d1e829613629c8e3b44cf61b58c5;l=295 to see whether the wrapped linker_input has the flag `-blah`. A different question which I won't go...

`cc_shared_library` wasn't designed with `objc_library` rules in mind so I'm surprised it even works with that small workaround. Looking quickly at the `objc_library` rule definition it doesn't announce that it...

No plans to work on this in the short term. I updated priorities.