rustc: Use llvm-ar for custom targets by default #31494
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The compiler currently vendors its own version of "llvm-ar" (not literally the binary but rather the library support) and uses it for all major targets by default (e.g. everything defined in `src/librustc_back/target`). All custom target specs, however, still search for an `ar` tool by default. This commit changes this default behavior to using the internally bundled llvm-ar with the GNU format. Currently all targets use the GNU format except for OSX which uses the BSD format (surely makes sense, right?), and custom targets can change the format via the `archive-format` key in custom target specs. I suspect that we can outright remove support for invoking an external `ar` utility, but I figure for now there may be some crazy target relying on that so we should leave support in for now.
|
r? @pnkfelix (rust_highfive has picked a reviewer for you, use r? to override) |
|
@bors r+ |
|
📌 Commit d66f394 has been approved by |
bors
added a commit
that referenced
this pull request
Feb 10, 2016
The compiler currently vendors its own version of "llvm-ar" (not literally the binary but rather the library support) and uses it for all major targets by default (e.g. everything defined in `src/librustc_back/target`). All custom target specs, however, still search for an `ar` tool by default. This commit changes this default behavior to using the internally bundled llvm-ar with the GNU format. Currently all targets use the GNU format except for OSX which uses the BSD format (surely makes sense, right?), and custom targets can change the format via the `archive-format` key in custom target specs. I suspect that we can outright remove support for invoking an external `ar` utility, but I figure for now there may be some crazy target relying on that so we should leave support in for now.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The compiler currently vendors its own version of "llvm-ar" (not literally the
binary but rather the library support) and uses it for all major targets by
default (e.g. everything defined in
src/librustc_back/target). All customtarget specs, however, still search for an
artool by default. This commitchanges this default behavior to using the internally bundled llvm-ar with the
GNU format.
Currently all targets use the GNU format except for OSX which uses the BSD
format (surely makes sense, right?), and custom targets can change the format
via the
archive-formatkey in custom target specs.I suspect that we can outright remove support for invoking an external
arutility, but I figure for now there may be some crazy target relying on that so
we should leave support in for now.