`apple_static_xcframework` rule from `rules_apple` fails in 6.0.0

[yuriyhanysh]

Description of the bug:

When the incompatible_enable_cc_toolchain_resolution flag is on, and the platform_mappings file is specified, apple_static_xcframework from rules_apple fails in 6.0.0rc1 and 6.0.0rc2.

The rule is working in this configuration in version 6.0.0-pre.20220517.1 but stopped working in 6.0.0-pre.20220520.1

Error is: ERROR: file 'stages/swift/package-arm64-apple-ios13.0-fl.a' is generated by these conflicting actions:

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Example project: https://github.com/yuriyhanysh/bazel-platform-mappings

Which operating system are you running Bazel on?

macOS Ventura 13.0.1

What is the output of bazel info release?

release 6.0.0rc2

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

git@github.com:yuriyhanysh/bazel-platform-mappings.git
4da1c4878d6a3855a318f2489d684c7ed8bbe5c3
4da1c4878d6a3855a318f2489d684c7ed8bbe5c3

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

rc2 full log:

bazel build //...

Starting local Bazel server and connecting to it...
ERROR: file 'stages/swift/package-arm64-apple-ios13.0-fl.a' is generated by these conflicting actions:
Label: //stages/swift:package
RuleClass: apple_static_xcframework rule
JavaActionClass: class com.google.devtools.build.lib.rules.cpp.CppLinkAction
Configuration: 05b42373f2c4f39355ce7947bb50d5c61c302e23f1bd044c738732a2c3f19329
Mnemonic: CppArchive
Action key: c43aefec1ae9af2ad133068b7fe40e163a35b544d428ea26c02290a8d59f8175, e67945f8d6520bf4321a614971b1a2e22cd3bdf36fbb97161c1b55844a6fc891
Progress message: Linking stages/swift/package-arm64-apple-ios13.0-fl.a
Action describeKey: Linking stages/swift/package-arm64-apple-ios13.0-fl.a
  Command: external/local_config_cc/libtool
  Argument: external/local_config_cc/libtool
  Argument: -D
  Argument: -no_warning_for_no_symbols
  Argument: -static
  Argument: -arch_only
  Argument: arm64
  Argument: -syslibroot
  Argument: __BAZEL_XCODE_SDKROOT__
  Argument: -o
  Argument: bazel-out/darwin_arm64-fastbuild/bin/stages/swift/package-arm64-apple-ios13.0-fl.a
  Argument: bazel-out/ios-sim_arm64-min13.0-applebin_ios-ios_sim_arm64-fastbuild-ST-fe30e415f334/bin/stages/swift/liblib.a
, Linking stages/swift/package-arm64-apple-ios13.0-fl.a
  Command: external/local_config_cc/libtool
  Argument: external/local_config_cc/libtool
  Argument: -D
  Argument: -no_warning_for_no_symbols
  Argument: -static
  Argument: -arch_only
  Argument: arm64
  Argument: -syslibroot
  Argument: __BAZEL_XCODE_SDKROOT__
  Argument: -o
  Argument: bazel-out/darwin_arm64-fastbuild/bin/stages/swift/package-arm64-apple-ios13.0-fl.a
  Argument: bazel-out/ios-arm64-min13.0-applebin_ios-ios_arm64-fastbuild-ST-30c5b20ba4c1/bin/stages/swift/liblib.a

PrimaryInput: File:[/private/var/tmp/_bazel_yuriy.hanysh/76bb78a5b3c5ed5d097cb950d8b80ea6/external/local_config_cc[source]]cc_wrapper.sh
PrimaryOutput: File:[[<execution_root>]bazel-out/darwin_arm64-fastbuild/bin]stages/swift/package-arm64-apple-ios13.0-fl.a
Owner information: ConfiguredTargetKey{label=//stages/swift:package, config=BuildConfigurationKey[05b42373f2c4f39355ce7947bb50d5c61c302e23f1bd044c738732a2c3f19329]}
MandatoryInputs: Attempted action contains artifacts not in previous action (first 5): 
    stages/swift/liblib.a
Previous action contains artifacts not in attempted action (first 5): 
    stages/swift/liblib.a
Outputs: are equal
ERROR: /Users/yuriy.hanysh/Documents/bazel-platform-mappings/stages/swift/BUILD.bazel:13:25: for stages/swift/package-arm64-apple-ios13.0-fl.a, previous action: action 'Linking stages/swift/package-arm64-apple-ios13.0-fl.a', attempted action: action 'Linking stages/swift/package-arm64-apple-ios13.0-fl.a'
ERROR: Analysis of target '//stages/swift:package' failed; build aborted: 
INFO: Elapsed time: 4.405s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (67 packages loaded, 1542 targets configured)

[fmeum]

Bisect points to https://github.com/bazelbuild/bazel/commit/b0487dc28eeb2ce3c0485cf0a21a5e69fbb00bc3, but that commit doesn't have an author listed.

[fmeum]

@bazel-io flag

[sgowroji]

@bazel-io fork 6.0.0

[meteorcloudy]

@keith Looks like there is some incompatible change in Bazel that rules_apple should adapt? (It's likely the Google version of rules_apple already did)

[keith]

@meteorcloudy which change specifically? AFAIUI incompatible_enable_cc_toolchain_resolution isn't generally supported still, so im not surprised things aren't working there

[meteorcloudy]

Oh I see, I missed that part. So this issue is basically under https://github.com/bazelbuild/rules_apple/issues/1765

[meteorcloudy]

@keith But based on the error message and the commit identified (https://github.com/bazelbuild/bazel/commit/b0487dc28eeb2ce3c0485cf0a21a5e69fbb00bc3), if we want to make --incompatible_enable_cc_toolchain_resolution work for rules_apple, should this be fixed in Bazel or rules_apple?

[keith]

I'm not super clear on every step to make that work, but I think it requires changes in both repos. My current thought is that it at least requires https://github.com/bazelbuild/bazel/pull/16619 and https://github.com/bazelbuild/rules_apple/pull/1533 but I'm not sure.

[meteorcloudy]

OK, in that case, I'll remove this issue as a release blocker for 6.0.

[meteorcloudy]

@yuriyhanysh Please let me know if you think this should still be a blocker for 6.0.

/cc @allevato as reviewer of the change.

[yuriyhanysh]

@meteorcloudy I'm afraid I'm missing some context here to suggest if this is a blocker.

incompatible_enable_cc_toolchain_resolution doesn't work with rules_apple, but somehow adding the platform_mappings file fixed this issue on the earlier 6.0.0 version. Was I just lucky with that?

In my case, the incompatible_enable_cc_toolchain_resolution flag is needed for non-apple targets. I guess I can turn it off for now and try to work around issues that I bump into, but then the question is, when should it work properly again? End of 2023?

If b0487dc fixes something else, I think we can remove this issue as a blocker for 6.0. Otherwise, can we live with reverted b0487dc until incompatible_enable_cc_toolchain_resolution is fixed for rules_apple? Is it correct to revert/update the b0487dc change if my case wasn't supposed to work anyway?

[meteorcloudy]

incompatible_enable_cc_toolchain_resolution doesn't work with rules_apple, but somehow adding the platform_mappings file fixed this issue on the earlier 6.0.0 version. Was I just lucky with that?

I believe it's just by luck that this has worked, @keith can confirm that.

when should it work properly again? End of 2023?

I guess this really depends on when rules_apple can add proper platform-based toolchain support.

If b0487dc fixes something else, I think we can remove this issue as a blocker for 6.0.

https://github.com/bazelbuild/bazel/commit/b0487dc28eeb2ce3c0485cf0a21a5e69fbb00bc3 was needed for some google internal use cases, I don't think we can easily revert this change. I think fixing this issue will be one of the blockers for rules_appple to support --incompatible_enable_cc_toolchain_resolution

[keith]

today at the very least platform_mappings are required to get anywhere with this stuff, but I guess I still don't know what is broken even once you have that.

[keith]

@meteorcloudy what values are used for target_system_name in your internal apple toolchain? I imagine that difference is the issue

[keith]

I assume they're the standard x86_64-apple-darwin, and maybe for simulator things like arm64-apple-ios-simulator, but I've tried various values w/o things working. In some cases the library we get back from cc_common.link is actually None, which seems strange!

[meteorcloudy]

@nglevin is the author of https://github.com/bazelbuild/bazel/commit/b0487dc28eeb2ce3c0485cf0a21a5e69fbb00bc3, who may have more context.

[meteorcloudy]

I did a quick search, looks like the target_system_name is a generated value in the form of {architecture}-apple-{platform}{version}{environment}

[keith]

things have changed a lot here now, is this one fixed?