| commit | 1f942ef9962ee39a000114b149ffd22962ac464a | [log] [tgz] |
|---|---|---|
| author | Mathieu Olivari <molivari@apple.com> | Tue Sep 02 14:22:33 2025 -0700 |
| committer | GitHub <noreply@github.com> | Tue Sep 02 14:22:33 2025 -0700 |
| tree | a58d01fe9cc7ce3477916ac9e0132c74eae035c4 | |
| parent | 3c286afb6597f66b1a0489a6712a524a25f1c71b [diff] |
Pass -object_path_lto <path> linker flag for LTO builds (#420) (#428) The following commit (in 1.23.0) was reverted recently (in 1.23.1): * commit 61b44d12df0834ae26d6e089271e14c6c9a239c8 * revert 4c51f10063687af77eabbbdc035124d798ca3a3f This patch is a new attempt at getting that feature merged, but without the LTO related issues that came up in the first patch. The difference is that we're adding that feature unconditionally now, as it won't hurt linking actions when LTO is disabled anyway. And enabling the bazel lto features changes the linking workflow in a way that isn't necessary on Apple platforms. Initial commit log below. --- This is needed for LTO builds, this is the path to which linker writes one big object file after performing link time optimisations, and then this object file would be used during final linking to create the App binary, without this file binary would contain invalid debug symbols, more info - https://github.com/bazelbuild/rules_swift/issues/1529 . Closes - https://github.com/bazelbuild/rules_swift/issues/1529 Co-authored-by: Sanju Naik <66404008+sanju-naik@users.noreply.github.com>
This repository contains the Apple CC toolchain, Apple related platforms and constraints definitions, and small helper functions for rules authors targeting Apple platforms.
If you want to build iOS, tvOS, visionOS, watchOS, or macOS apps, use rules_apple.
If you want to build Swift use rules_swift.
See the documentation for the helper rules provided by this repository.
Copy the MODULE.bazel or WORKSPACE snippets from the releases page into your project.
The Apple CC toolchain in this repository provides toolchains for building for Apple platforms besides macOS. Since Bazel 7 this toolchain is required when targeting those platforms.
NOTE: This toolchain requires a full Xcode installation, not just the Xcode Command Line Tools. If you only need to build for macOS and don't want to require a full Xcode installation in your build, use the builtin Unix toolchain provided by Bazel.
For Bazel 7+ the only setup that is required is to have apple_support in your MODULE.bazel (even if you're not referencing it directly) or WORKSPACE, which you can copy from the releases page into your project.
If you also depend on rules_cc, apple_support must come above rules_cc in your MODULE.bazel or WORKSPACE file because Bazel selects toolchains based on which is registered first.
There are many different flags you can flip to configure how the toolchain works. Here are some of the more commonly useful ones:
DEVELOPER_DIR in the environment. This is recommended so that the toolchain can be invalidated when the DEVELOPER_DIR changes, which ensures that toolchain binaries will be rebuilt with the new version of Xcode so that caches are correctly shared across machines.BAZEL_ALLOW_NON_APPLICATIONS_XCODE=1 in the environment (or using --repo_env) allows the toolchain to discover Xcode versions outside of the /Applications directory to avoid header inclusion errors from bazel. This is not enabled by default because /Applications is the standard directory, and this improves toolchain setup performance.