`apple_static_xcframework` rule from `rules_apple` fails in 6.0.0 #16827

yuriyhanysh · 2022-11-23T09:32:15Z

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)

The text was updated successfully, but these errors were encountered:

fmeum · 2022-11-23T10:19:12Z

Bisect points to b0487dc, but that commit doesn't have an author listed.

fmeum · 2022-11-23T10:20:19Z

@bazel-io flag

sgowroji · 2022-11-23T10:58:04Z

@bazel-io fork 6.0.0

meteorcloudy · 2022-11-28T08:28:37Z

@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 · 2022-11-28T16:21:35Z

@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 · 2022-11-28T16:33:39Z

Oh I see, I missed that part. So this issue is basically under bazelbuild/rules_apple#1765

meteorcloudy · 2022-11-28T16:36:56Z

@keith But based on the error message and the commit identified (b0487dc), if we want to make --incompatible_enable_cc_toolchain_resolution work for rules_apple, should this be fixed in Bazel or rules_apple?

keith · 2022-11-28T16:53:00Z

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 #16619 and bazelbuild/rules_apple#1533 but I'm not sure.

meteorcloudy · 2022-11-28T17:16:50Z

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

meteorcloudy · 2022-11-29T10:21:39Z

@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 · 2022-11-29T17:13:46Z

@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 · 2022-11-30T11:05:57Z

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.

b0487dc 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 · 2022-11-30T16:41:47Z

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 · 2023-01-09T19:07:16Z

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

keith · 2023-01-09T19:11:46Z

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 · 2023-01-10T15:00:24Z

@nglevin is the author of b0487dc, who may have more context.

meteorcloudy · 2023-01-11T09:48:27Z

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 · 2023-12-18T18:40:02Z

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

sgowroji added platform: apple team-Rules-ObjC Issues for Objective-C maintainers untriaged type: bug labels Nov 23, 2022

bazel-io added the potential release blocker Flagged by community members using "@bazel-io flag". Should be added to a release blocker milestone label Nov 23, 2022

bazel-io removed the potential release blocker Flagged by community members using "@bazel-io flag". Should be added to a release blocker milestone label Nov 23, 2022

bazel-io mentioned this issue Nov 23, 2022

[6.0.0] apple_static_xcframework rule from rules_apple fails in 6.0.0 #16828

Closed

keith added P2 We'll consider working on this in future. (Assignee optional) and removed untriaged labels Dec 18, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

`apple_static_xcframework` rule from `rules_apple` fails in 6.0.0 #16827

`apple_static_xcframework` rule from `rules_apple` fails in 6.0.0 #16827

yuriyhanysh commented Nov 23, 2022

fmeum commented Nov 23, 2022

fmeum commented Nov 23, 2022

sgowroji commented Nov 23, 2022

meteorcloudy commented Nov 28, 2022

keith commented Nov 28, 2022

meteorcloudy commented Nov 28, 2022

meteorcloudy commented Nov 28, 2022

keith commented Nov 28, 2022

meteorcloudy commented Nov 28, 2022

meteorcloudy commented Nov 29, 2022

yuriyhanysh commented Nov 29, 2022

meteorcloudy commented Nov 30, 2022

keith commented Nov 30, 2022

keith commented Jan 9, 2023 •

edited

Loading

keith commented Jan 9, 2023

meteorcloudy commented Jan 10, 2023 •

edited

Loading

meteorcloudy commented Jan 11, 2023

keith commented Dec 18, 2023

apple_static_xcframework rule from rules_apple fails in 6.0.0 #16827

apple_static_xcframework rule from rules_apple fails in 6.0.0 #16827

Comments

yuriyhanysh commented Nov 23, 2022

Description of the bug:

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

Which operating system are you running Bazel on?

What is the output of bazel info release?

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

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

Have you found anything relevant by searching the web?

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

fmeum commented Nov 23, 2022

fmeum commented Nov 23, 2022

sgowroji commented Nov 23, 2022

meteorcloudy commented Nov 28, 2022

keith commented Nov 28, 2022

meteorcloudy commented Nov 28, 2022

meteorcloudy commented Nov 28, 2022

keith commented Nov 28, 2022

meteorcloudy commented Nov 28, 2022

meteorcloudy commented Nov 29, 2022

yuriyhanysh commented Nov 29, 2022

meteorcloudy commented Nov 30, 2022

keith commented Nov 30, 2022

keith commented Jan 9, 2023 • edited Loading

keith commented Jan 9, 2023

meteorcloudy commented Jan 10, 2023 • edited Loading

meteorcloudy commented Jan 11, 2023

keith commented Dec 18, 2023

`apple_static_xcframework` rule from `rules_apple` fails in 6.0.0 #16827

`apple_static_xcframework` rule from `rules_apple` fails in 6.0.0 #16827

What is the output of `bazel info release`?

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

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

keith commented Jan 9, 2023 •

edited

Loading

meteorcloudy commented Jan 10, 2023 •

edited

Loading