Marketing and "release" of Mach-O lld

Is it safe to say that Mach-O lld is, at this point, an effective drop-in replacement for ld64? Or at least specifically for C, C++, and Rust projects? If so, I think it would be good to spread the word. For example, when I search for “mach-o lld” in the Rust subreddit, I don’t see any results. And many developers and projects I’ve interacted with, such as here, seem unaware of the current state of Mach-O lld.

Also, for the new users of lld, is there a prominent link to a simple prebuilt binary somewhere? I don’t see one at . Alternatively, there could be directions provided to use brew install llvm, although that formula includes a ton of unnecessary stuff for lld and doesn’t symlink it by default.

Thanks for bringing this up. I definitely think we could do more to publicize LLD, though we might want to do some prep work before that.

Is it safe to say that Mach-O lld is, at this point, an effective drop-in replacement for ld64? Or at least specifically for C, C++, and Rust projects?

AFAIK, thus far most of the testing has been against a few large projects that the dev team members support at their own companies. I believe that covers C, C++, as well as Obj-C and Swift codebases; I have no idea about how many (if any) Rust-based builds we’ve tested. One thing we could consider before publicizing is to try and build a bunch of homebrew packages using LLD. (Alternatively, we could publicize it and hope someone else does this for us.)

I also just recently landed support for proper pruning of EH frames to LLD, which should go out in LLVM-15. Without that, exception-using C++ builds will end up unnecessarily bloated. So I think we should either wait till the LLVM-15 release to publicize this, or to tell people to build from HEAD for now.

@int3 on this topic - the last time I tried to build LLVM itself with the new linker there was a lot of errors in the cmake scripts. Have you or anyone else looked into this?

I think we’ve done it for a limited set of build config settings, and I know @leevince is looking at building LLVM internally at Meta using LLD. I think @thakis may have done some experimentation too, and probably others I don’t recall atm.

How long ago did you attempt this build, and which build config settings did you use?

Based on D122109, @petrhosek must’ve tried it too

It was probably the 14.x release - but I should rebuild with HEAD and see, just need to find some time :slight_smile:

1 Like

The rust toolchain ships rust-lld. It used to work for my projects on OSX. They are discussing to improve the user experience:

1 Like

LLD should be building LLVM correctly with HEAD (which is more or less with what we use). If not, I’d be curious to know what errors you faced and what build flags you used.


We have been linking LLVM with Mach-O LLD for a few weeks now without problems.

The only issue I’m aware of is lld Mach-O backend reports a warning when using DWARF 5 · Issue #51668 · llvm/llvm-project · GitHub but that only comes up when you explicitly request DWARF 5 because Clang still defaults to DWARF 4 on Darwin.


The llvm/gn bot at continuously builds with lld/mac as host linker.

I’ve tried using lld/mac as host linker in the script that builds chromium’s toolchain package. Almost everything works fine there, too.

(The things that don’t work:

  • Last time I tried there was a mystery crash when doing a bootstrap build with PGO, see 1267227 - chromium - An open-source project to help move the web forward. - Monorail . I haven’t gotten to the bottom of it. I also haven’t tried in a few months though, so not sure if it’s even still a problem. We were still targeting macOS 10.9 (or even 10.7) back then, and lld/mac can’t target versions that old, so that might’ve been part of the problem. Maybe it’s better now.

  • For $reasons, we still build a 32-bit intel emulator runtime library, and lld/mac doesn’t support 32-bit intel. We won’t need that runtime library for much longer, so this’ll fix itself in time.

1 Like