[build] fix lld linker path #2898
Conversation
.bazelrc
Outdated
| @@ -320,7 +320,7 @@ build:release_macos --linkopt="-Wl,-no_function_starts" | |||
| # We could use Xcode 16's -Wl,-deduplicate option instead, but LLD's ICF appears to be superior. | |||
| # We also want to enable ICF for Linux, but there it causes warnings when dynamically linking with | |||
| # libc++. | |||
| build:macos_lld --linkopt="-fuse-ld=/opt/homebrew/bin/ld64.lld" | |||
| build:macos_lld --linkopt=-fuse-ld=lld --linkopt=--ld-path=/opt/homebrew/bin/ld64.lld | |||
There was a problem hiding this comment.
Q: Is there an assertion in anywhere in the build pipeline so that homebrew is installed and these expectations (such as /homebrew/bin/ld64.lld are available?
There was a problem hiding this comment.
With #2884, macos_lld is a build configuration we opt in to in the release job, and we run brew install lld before that. Homebrew itself is always installed in the image.
Now that I think about it the /opt/homebrew/bin/ld64.lld requirement is precisely why this is actually failing – the homebrew binary paths are different on x86 and Apple Silicon, and since the release job is on x86 we'll need different paths here.
There was a problem hiding this comment.
Figured out a way to not use an absolute path – glad there's a platform-independent option!
This appears to be needed for the clang driver to find LLD when using older clang versions.
fhanau
force-pushed
the
felix/101024-macOS-ci
branch
from
2fd4ec1
to
4f2fe3e
Compare
This appears to be needed for the clang driver to find LLD when using older clang versions.
=============
This (hopefully) fixes macOS CI release builds.