Don't pass -fno-use-linker-plugin on OS X #17192
Conversation
|
This also breaks with Clang on Linux. It should probably only pass it on Windows. |
|
What would be the correct path here? As far as I see, the actual compiler isn't currently detected, just the OS. |
|
Can you change the if statement to |
|
Rust makefiles do know when clang's being used ($CFG_USING_CLANG), so we could set |
|
@alexcrichton long-term, should we expose which compiler we are using for linking ? (I actually went ahead and made a branch that does this. Its pretty simple; I'll put up a PR after I ensure it bootstraps.) |
|
closing in favor of PR #17231 |
|
Reopening in case I never revise #17231 |
The detected categorization is memoized in the Session object. The link.rs backend then uses this information when choosing options to add to the `cc` command line arguments (currently it just affects a single option that will cause a hard error in clang in the future). This is meant to be, in part, a more robust version of PR rust-lang#17192. As drive-bys: * fix an english grammar mistake in a comment. * replace the use of `String` with `&str` for the program names corresponding `cc` and `ar`, avoiding unnecessary string copies but more importantly making the code overall look nicer. :) Fix rust-lang#17214. (Addressed review nits from nrc and acrichto.)
|
I don't really understand why we need to pass this at all. Why do we need to explicitly disable the linker plugin for GCC, but not Clang's linker plugin? |
|
We're now bundling mingw executables with the windows distribution, and we want to explicitly disable the linker plugin on windows to avoid pulling in lots of extra dependencies we don't want to bundle. @skade, could you modify the if-clause to only pass this argument on windows? This looks like it's breaking more recent OSX builds. |
Only pass -fno-use-linker-plugin on Windows where it avoids pulling in dependencies. Passing it to clang on OS X and Linux would make it fail though.
skade
force-pushed
the
fix-osx-linking
branch
from
6c463e0 to
e9c4efb
Compare
|
@alexcrichton sure, here you go. Builds on my OS X machine (tm). |
Don't pass -fno-use-linker-plugin on OS X as clang does not accept it. clang fails linking with: ``` error: linking with `cc` failed: exit code: 1 ... arg list omitted... note: clang: error: unknown argument: '-fno-use-linker-plugin' [-Wunused-command-line-argument-hard-error-in-future] clang: note: this will be a hard error (cannot be downgraded to a warning) in the future ``` clang version: ``` $ clang -v Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.2.0 Thread model: posix ```
Fix source_range for INT_NUMBER in completion fix rust-lang#17179. Previously r-a use `TextRange::empty(self.position.offset)` as `source_range` for `INT_NUMBER`, so the `text_edit` would always be an insertion, which results in rust-lang#17179. This PR changed it by using `text_range` of `original_token` (same as `IDENT`).
Don't pass -fno-use-linker-plugin on OS X as clang does not accept it.
clang fails linking with:
clang version: