-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rustc should attempt to use the gold linker by default, but this breaks Debian Wheezy because of obsolete gcc #30783
Comments
If this can't be fixed in the next week it should probably be reverted to rethink the migration strategy. |
Aw man this is unfortunate. Agree on reverting if we can't figure anything else out. I guess an "ideal solution" would be if gcc/clang read an environment variable as well as an argument, but I unfortunately don't see such an environment variable in clang at least. We can maybe try to parse something like I wonder, how is one supposed to tell gcc on wheezy to use gold? |
@xitep suggested how to detect gcc's support for this. Unfortunately it involves running gcc an extra time. I can't think of anything better. |
It's true that's a possibility, I would likely prefer to see that as the compiler attempts to run the entire linker and then parses the error message if one shows up, and only then is gold removed if the entire linker fails. That way we'd only run gcc once if possible, and twice in the worst case. That being said that's still a pretty big hit for distros because it's 2 times on all compiles, which is pretty unfortunate :( |
I actually like the idea of environment variables from a user perspective. If I'd be able to set |
Oh sorry I meant moreso the compiler sets an environment variable which |
"I wonder, how is one supposed to tell gcc on wheezy to use gold?": it seems just by installing binutils-gold. |
An alternative to |
Hm detecting whether |
Assuming we add some way for the user to specify "disable gold", we could issue a warning when we run gcc twice, recommending that the user change their rustc invocation (or host configuration) accordingly |
(that way it's only "2 times until user changes host configuration to disable gold usage on rustc " Which is better than 2 times always |
@pnkfelix perhaps yeah, but at that point I'd probably be more in favor of just disabling by default. |
This reverts commit 34dc0e0. cc #30783 #30784 #29974 r? @alexcrichton
I read @xitep's comment as "those who want to use gold can simply replace ld with a symlink to it". |
Or use the distro's mechanism for switching (such as |
Removing regression/nomination tags as this was fixed, leaving open as a reference to why we reverted ld.gold |
Since we're leaving this open, I've changed the title to something potentially more actionable. |
This is certainly part of a broader debate, but how long are we willing to support obsolete distros? Wheezy is already obsolete as of Jessie, and as of Stretch next year it will be doubly obsolete. |
personally, i'm stuck with wheezy on a few systems for this year. regarding this particular issue, making a my point in a broader sense: it seems to me that supporting a platform which is merely a few years old and is going to be supported for some more makes rust an attractive alternative to other languages (in particular c++ and java.) i wouldn't be surprised if i wasn't the only one having to deal with "such old systems" in production. |
hello, i just got aware of RUSTFLAGS which seems like a solution to my originally reported problem. given the desire to use ld.gold by default, i think it might be worth considering to enable that default again now and use |
I propose that we revisit this around February 2017, since that's approximately the Stretch release date, by which point Wheezy will be even more emphatically obsolete. Which isn't to suggest that we shouldn't care about people still using Wheezy by then, but we need to prioritize the needs of the greatest proportion of our users, and gold-by-default is a significant speed win. |
@bstrie: small update, the release date for Debian Stretch has been set at 17 June 2017. |
Stretch is now (and has been for a few months) stable, Jessie is oldstable, and Wheesy is in "LTS" until May 2018. Can we enable ld.gold by default yet? CC @rust-lang/compiler |
Or is it @rust-lang/dev-tools ? |
Note that Wheezy is going to have some extra support time. https://raphaelhertzog.com/2018/02/20/time-to-join-extended-long-term-support-for-debian-7-wheezy/ But... why does rust invoke ld through gcc anyways? |
Even if some people and companies want to keep supporting Wheezy, does that mean that recent rustc versions need to do the same? |
Well, Firefox builds are done on Debian Wheezy at the moment... |
I'm going to close in favor of #39915, which is tracking a move to LLD by default. I don't think investing in a move to gold first makes sense. |
Original report.
Rust nightly uses the gold linker where it can by passing
-fuse-ld=gold
to gcc when it sees that ld.gold exists. Unfortunately, even ifld.gold
existsgcc
may not understand-fuse-ld=gold
.This distro came out in May 2013, so it's not that old.
The text was updated successfully, but these errors were encountered: