Skip to content
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

Swift host tools compiled with wrong cpu on Apple Silicon #12671

Closed
thii opened this issue Dec 7, 2020 · 14 comments
Closed

Swift host tools compiled with wrong cpu on Apple Silicon #12671

thii opened this issue Dec 7, 2020 · 14 comments
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) platform: apple team-Rules-CPP Issues for C++ rules type: bug

Comments

@thii
Copy link
Member

thii commented Dec 7, 2020

Host tools are being compiled for x86_64 cpu when compiling a target that uses them on an arm Mac, with an arm Bazel.

# BUILD
load("@build_bazel_rules_swift//swift:swift.bzl", "swift_binary")

genrule(
    name = "hello_swift",
    outs = ["hello.swift"],
    cmd = """echo 'print("Hello")' > $@""",
)

swift_binary(
    name = "hello_swift_bin",
    srcs = [":hello_swift"],
)

genrule(
    name = "a",
    outs = ["a.out"],
    cmd = """$(execpath :hello_swift_bin) > $@""",
    tools = [":hello_swift_bin"],
)
$ bazel build a
...
SUBCOMMAND: # //:hello [action 'Compiling Swift module hello [for host]', configuration: 130cff6c5881621671f254bf93eadfab04237d1f78aac0f4e2233c4b12d50eee, execution platform: @local_config_platform//:host]
(cd /private/var/tmp/_bazel_user/c65ad10e7591af2b858f41477e1f1a20/execroot/build_bazel_rules_swift && \
  exec env - \
    APPLE_SDK_PLATFORM=MacOSX \
    APPLE_SDK_VERSION_OVERRIDE=11.0 \
    XCODE_VERSION_OVERRIDE=12.2.0.12B45b \
  bazel-out/host/bin/tools/worker/worker swiftc @bazel-out/host/bin/hello.swiftmodule-0.params)
SUBCOMMAND: # //:hello [action 'Linking hello [for host]', configuration: 130cff6c5881621671f254bf93eadfab04237d1f78aac0f4e2233c4b12d50eee, execution platform: @local_config_platform//:host]
(cd /private/var/tmp/_bazel_user/c65ad10e7591af2b858f41477e1f1a20/execroot/build_bazel_rules_swift && \
  exec env - \
    APPLE_SDK_PLATFORM=MacOSX \
    APPLE_SDK_VERSION_OVERRIDE=11.0 \
    PATH=/bin:/usr/bin \
    XCODE_VERSION_OVERRIDE=12.2.0.12B45b \
  external/local_config_cc/cc_wrapper.sh -lc++ -fobjc-link-runtime -Wl,-S -o bazel-out/host/bin/hello bazel-out/host/bin/hello_objs/hello.swift.o -headerpad_max_install_names -Wl,-rpath,/usr/lib/swift -Wl,-rpath,__BAZEL_XCODE_DEVELOPER_DIR__/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx -F__BAZEL_XCODE_DEVELOPER_DIR__/Platforms/MacOSX.platform/Developer/Library/Frameworks -L__BAZEL_XCODE_DEVELOPER_DIR__/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx -ObjC -Wl,-objc_abi_version,2 -L/usr/lib/swift -no-canonical-prefixes -target arm64-apple-macosx '-mmacosx-version-min=11.0')
ERROR: /Users/user/forks/rules_swift/BUILD:26:13: Linking hello [for host] failed: (Exit 1): cc_wrapper.sh failed: error executing command external/local_config_cc/cc_wrapper.sh -lc++ -fobjc-link-runtime -Wl,-S -o bazel-out/host/bin/hello bazel-out/host/bin/hello_objs/hello.swift.o -headerpad_max_install_names -Wl,-rpath,/usr/lib/swift ... (remaining 10 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox cc_wrapper.sh failed: error executing command external/local_config_cc/cc_wrapper.sh -lc++ -fobjc-link-runtime -Wl,-S -o bazel-out/host/bin/hello bazel-out/host/bin/hello_objs/hello.swift.o -headerpad_max_install_names -Wl,-rpath,/usr/lib/swift ... (remaining 10 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox
ld: warning: ignoring file bazel-out/host/bin/hello_objs/hello.swift.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
Undefined symbols for architecture arm64:
  "_main", referenced from:
     implicit entry/start for main executable
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Target //:a failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 52.627s, Critical Path: 15.98s
INFO: 214 processes: 7 internal, 206 darwin-sandbox, 1 worker.
FAILED: Build did NOT complete successfully
$ cat bazel-out/host/bin/hello_swift_bin.swiftmodule-0.params
-target
x86_64-apple-macosx11.0
-sdk
__BAZEL_XCODE_SDKROOT__
-F__BAZEL_XCODE_DEVELOPER_DIR__/Platforms/MacOSX.platform/Developer/Library/Frameworks
-I__BAZEL_XCODE_DEVELOPER_DIR__/Platforms/MacOSX.platform/Developer/usr/lib
-emit-object
-output-file-map
bazel-out/host/bin/hello_swift_bin.output_file_map.json
-emit-module-path
bazel-out/host/bin/hello_swift_bin.swiftmodule
-emit-objc-header-path
bazel-out/host/bin/hello_swift_bin-Swift.h
-DNDEBUG
-O
-Xwrapped-swift=-ephemeral-module-cache
-Xcc
-iquote.
-Xcc
-iquotebazel-out/host/bin
-Xfrontend
-color-diagnostics
-enable-batch-mode
-module-name
hello_swift_bin
-Xcc
-Os
-Xcc
-DNDEBUG=1
-Xcc
-Wno-unused-variable
-Xcc
-Winit-self
-Xcc
-Wno-extra
bazel-out/host/bin/hello.swift

It works fine if we build the tool directly with --macos_cpus=arm64.

Tools written in C/C++ work fine.

I'm using a custom build for darwin arm64 at https://github.com/thii/bazel/tree/4.0.0-darwin_arm64 (based on 4.0.0rc2), so there’s a possibility that it’s a problem with my build.

@keith
Copy link
Member

keith commented Dec 7, 2020

@keith
Copy link
Member

keith commented Dec 7, 2020

Seems like the issue is coming from here

this.macosCpus = (options.macosCpus == null || options.macosCpus.isEmpty())
? ImmutableList.of(AppleCommandLineOptions.DEFAULT_MACOS_CPU)
: ImmutableList.copyOf(options.macosCpus);

@keith
Copy link
Member

keith commented Dec 7, 2020

It makes sense to me that you building directly with --macos_cpus works, but it doesn't work as a tool because in that case what you'd really need would be --host_macos_cpus.

@thii
Copy link
Member Author

thii commented Dec 7, 2020

Getting the same result with --host_cpu=darwin_arm64.

@keith
Copy link
Member

keith commented Dec 7, 2020 via email

@thii
Copy link
Member Author

thii commented Dec 7, 2020

cc_binary tools work because they're not being passed a -target at all, so they'd just be built for the default target. Maybe we can do the same with Swift?

@keith
Copy link
Member

keith commented Dec 7, 2020

I think we need to fix this in bazel itself otherwise I imagine many other things will also be incorrect

@keith
Copy link
Member

keith commented Dec 7, 2020

This is actually probably the same case as if you try to build for the simulator on a apple silicon machine, it will build a x86_64 simulator binary, I assume the fix for both will be similar

@thii
Copy link
Member Author

thii commented Dec 9, 2020

Our current workaround is invoking the tool with swift run.

@keith
Copy link
Member

keith commented Dec 9, 2020

@susinmotion can you move this issue to the bazel repo?

@susinmotion
Copy link
Contributor

I'm afraid I don't have permissions in rules_swift, so I can't see the option to move this issue. @allevato, any chance you have permissions to transfer this issue?

@allevato allevato transferred this issue from bazelbuild/rules_swift Dec 9, 2020
@allevato
Copy link
Member

allevato commented Dec 9, 2020

@susinmotion Transferred!

@thii thii changed the title Host tools compiled with wrong cpu on Apple Silicon Swift host tools compiled with wrong cpu on Apple Silicon Dec 9, 2020
@aiuto
Copy link
Contributor

aiuto commented Jan 7, 2021

cc: @susinmotion

@aiuto aiuto added the team-Rules-CPP Issues for C++ rules label Jan 7, 2021
@oquenchil oquenchil added P3 We're not considering working on this, but happy to review a PR. (No assignee) type: bug and removed untriaged labels Jan 12, 2021
keith added a commit to keith/bazel that referenced this issue May 6, 2021
With Apple Silicon machines host tools that use the apple_binary, or
apple fragment to fetch the CPU would be built for the wrong
architecture, even though the C++ logic would correctly identify the
host CPU. This changes this hardcoded value to correctly determine Apple
Silicon as arm64, and otherwise fallback to x86_64.

Fixes bazelbuild#12671
@keith
Copy link
Member

keith commented May 6, 2021

#13440

katre pushed a commit that referenced this issue Jul 12, 2021
With Apple Silicon machines host tools that use the apple_binary, or
apple fragment to fetch the CPU would be built for the wrong
architecture, even though the C++ logic would correctly identify the
host CPU. This changes this hardcoded value to correctly determine Apple
Silicon as arm64, and otherwise fallback to x86_64.

Fixes #12671

Closes #13440.

PiperOrigin-RevId: 373421791
katre pushed a commit to katre/bazel that referenced this issue Jul 13, 2021
With Apple Silicon machines host tools that use the apple_binary, or
apple fragment to fetch the CPU would be built for the wrong
architecture, even though the C++ logic would correctly identify the
host CPU. This changes this hardcoded value to correctly determine Apple
Silicon as arm64, and otherwise fallback to x86_64.

Fixes bazelbuild#12671

Closes bazelbuild#13440.

PiperOrigin-RevId: 373421791
katre pushed a commit to katre/bazel that referenced this issue Jul 13, 2021
With Apple Silicon machines host tools that use the apple_binary, or
apple fragment to fetch the CPU would be built for the wrong
architecture, even though the C++ logic would correctly identify the
host CPU. This changes this hardcoded value to correctly determine Apple
Silicon as arm64, and otherwise fallback to x86_64.

Fixes bazelbuild#12671

Closes bazelbuild#13440.

PiperOrigin-RevId: 373421791
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) platform: apple team-Rules-CPP Issues for C++ rules type: bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants