michaeleisel / zld

A faster version of Apple's linker
MIT License
1.19k stars 50 forks source link
ios linker macos

NOTE: zld is now archived, consider using lld instead. More info is here.

zld

A faster version of Apple's linker

Introduction

For large projects, the linking phase (explanation) can significantly increase incremental build times. This project is a fork of the Apple linker, ld. It is a drop-in replacement that can substantially speed things up.

Note: it is only intended for debug builds, to make debugging faster.

Performance

Feel free to file an issue if you find that linking is not at least 40% faster for your case (make sure to run it twice in a row to ensure that caches have been generated). Further benchmark details can be found here.

Is it worth it for my project?

It all depends on your risk tolerance and how much you value the speedup in incremental build time. When linking takes more than one second, I'd cut that time in half as the estimated time with this new linker. If that difference is compelling to you, then it'd be worth trying out. Personally, I'd use it in projects with an existing link time of even 500ms (but I am an impatient tinkerer).

Stability

zld is forked from the most recently open-sourced version of ld. It's used by thousands of developers across many of the largest apps in the world. Without a few optimizations around hashing, it would produce byte-for-byte the same executables as the open-source one. Although it's not ideal to mix compiler and linker toolchain versions, the open-source one is fairly recent. zld will continue to be updated with each new version of ld as it is released.

Installation

Below are the installation methods. Note that, if you someday install a newer version of Xcode and zld doesn't work with it, it may be that your version of zld is now too far behind that of the linker shipped in Xcode. In that case, check back here for the latest zld release to fix the problem.

Note: The Xcode app must be installed for zld to work (not just the Xcode command line tools)

Pre-built binary

The pre-built binary for the latest release is here.

Building from source

Usage

If using Xcode:

Get the path of zld from which zld, then add -fuse-ld=<path to zld> -Wl,-zld_original_ld_path,$(DT_TOOLCHAIN_DIR)/usr/bin/ld to "Other Linker Flags" in the build settings (debug configuration). That -zld_original_ld_path provides the path to the linker Xcode would otherwise use, which is important because there are certain known cases (e.g. arm64_32 and Catalyst) where zld knows that it has issues and will silently use that linker instead. Fixing these cases is a work-in-progress (largely blocked by Apple being slow to release source code).

If using Bazel:

Add these to your .bazelrc or pass them to your command line.

build --linkopt=-fuse-ld=<path to zld>
build --linkopt=-Wl,-zld_original_ld_path,__BAZEL_XCODE_DEVELOPER_DIR__/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld

Note that you will need to disable sandbox for this to work now. Additionally, to make the linking actions cacheable, the path to zld must be deterministic (e.g. /tmp/zld-09ea158, where 09ea158 is zld version).

Another option to use zld in Bazel is via rules_apple_linker.

If using Rust:

You can edit ~/.cargo/config to add a linker flag, e.g.:

[target.x86_64-apple-darwin]
# For Apple silicon:
# [target.aarch64-apple-darwin]

rustflags = ["-C", "link-arg=-fuse-ld=<path to zld>"]

Caching

By default, zld stores some metadata in /tmp/zld-... to speed things up. This is the first step towards making zld a truly incremental linker. Currently, the only things that are stored are object file and library names.

Why is it faster?

Apple's approach is a very reasonable one, using C++ with STL data structures. However, there are a number of ways in which zld has sped things up, for instance:

Other things to speed up linking

Whether you use this project or not, there are a number of things that can speed linking up (again, this is only for debug builds):

Contributing

The biggest way to contribute to zld is to file issues! If you encountered any problems, feel free to file an issue, and you can expect a prompt response.

Special thanks to @dmaclach's ld64, which helped with building ld.