Skip to content
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

Closed
brson opened this issue Jan 8, 2016 · 28 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue.

Comments

@brson
Copy link
Contributor

brson commented Jan 8, 2016

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 if ld.gold exists gcc may not understand -fuse-ld=gold.

This distro came out in May 2013, so it's not that old.

@brson brson added regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. I-nominated labels Jan 8, 2016
@brson
Copy link
Contributor Author

brson commented Jan 11, 2016

If this can't be fixed in the next week it should probably be reverted to rethink the migration strategy.

@alexcrichton
Copy link
Member

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 /etc/issue but that seems pretty sketchy.

I wonder, how is one supposed to tell gcc on wheezy to use gold?

@brson
Copy link
Contributor Author

brson commented Jan 12, 2016

@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.

@alexcrichton
Copy link
Member

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 :(

@xitep
Copy link

xitep commented Jan 12, 2016

I actually like the idea of environment variables from a user perspective. If I'd be able to set RUSTC_DISABLE_GOLD=1 (or similar) in one of my login scripts to the system I'd be totally happy (right now my solution is quite ugly with wrapping rustc with custom scripts). So far, I think, rustc itself doesn't interpret any envs, does it? So it'd be new territory with its own set of problems I guess.

@alexcrichton
Copy link
Member

Oh sorry I meant moreso the compiler sets an environment variable which gcc then interprets rather than the other way around. I'd personally prefer to avoid too many environment variables for the rustc compiler.

@xitep
Copy link

xitep commented Jan 12, 2016

"I wonder, how is one supposed to tell gcc on wheezy to use gold?": it seems just by installing binutils-gold. /usr/bin/ld becomes a symlink to /usr/bin/ld.gold.

@xitep
Copy link

xitep commented Jan 12, 2016

An alternative to /etc/issue might also be /etc/debian_version. But using these files seems very fragile to me :/ And adding dependencies on such external files will probably make the code in rustc unmaintainable in some future.

@alexcrichton
Copy link
Member

Hm detecting whether ld is a symlink and whether it points to ld.gold seems reasonable, but there's still a possibility that the symlink isn't there, ld.gold exists, and -fuse-ld=gold isn't accepted unfortunately

@pnkfelix
Copy link
Member

@alexcrichton

That being said that's still a pretty big hit for distros because it's 2 times on all compiles, which is pretty unfortunate

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

@pnkfelix
Copy link
Member

(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

@alexcrichton
Copy link
Member

@pnkfelix perhaps yeah, but at that point I'd probably be more in favor of just disabling by default.

@vadimcn
Copy link
Contributor

vadimcn commented Jan 16, 2016

I read @xitep's comment as "those who want to use gold can simply replace ld with a symlink to it".

@birkenfeld
Copy link
Contributor

Or use the distro's mechanism for switching (such as update-alternatives in Debian).

@alexcrichton
Copy link
Member

Removing regression/nomination tags as this was fixed, leaving open as a reference to why we reverted ld.gold

@alexcrichton alexcrichton added A-tools and removed I-nominated regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. labels Jan 27, 2016
@bstrie bstrie changed the title Nightly does not work on some Debian Wheezy because gcc doesn't support gold. rustc cannot use gold on some Debian Wheezy because gcc doesn't support gold. Mar 25, 2016
@bstrie
Copy link
Contributor

bstrie commented Mar 25, 2016

Since we're leaving this open, I've changed the title to something potentially more actionable.

@bstrie
Copy link
Contributor

bstrie commented Mar 25, 2016

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.

@xitep
Copy link

xitep commented Mar 26, 2016

personally, i'm stuck with wheezy on a few systems for this year. regarding this particular issue, making a rustc wrapper as suggested by eddyb in the original issue worked just fine for me. the only pain point was to preserve this wrapper upon updates by multirust (but that's something i'm not doing often on these systems.)

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.

@xitep
Copy link

xitep commented May 26, 2016

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 export RUSTFLAGS="-C disable-gold" on such old platforms. what do you think?

@bstrie
Copy link
Contributor

bstrie commented Jul 14, 2016

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 bstrie changed the title rustc cannot use gold on some Debian Wheezy because gcc doesn't support gold. rustc should attempt to use the gold linker by default, but this breaks Debian Wheezy because of obsolete gcc Jul 14, 2016
@Mark-Simulacrum Mark-Simulacrum added T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. and removed T-tools labels May 24, 2017
@sanmai-NL
Copy link

@bstrie: small update, the release date for Debian Stretch has been set at 17 June 2017.

@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 24, 2017
@SimonSapin
Copy link
Contributor

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

@SimonSapin
Copy link
Contributor

Or is it @rust-lang/dev-tools ?

@glandium
Copy link
Contributor

glandium commented Apr 3, 2018

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?

@SimonSapin
Copy link
Contributor

Even if some people and companies want to keep supporting Wheezy, does that mean that recent rustc versions need to do the same?

@glandium
Copy link
Contributor

glandium commented Apr 3, 2018

Well, Firefox builds are done on Debian Wheezy at the moment...

@workingjubilee
Copy link
Member

It's 2020.
It's time for
the_gold_experience

@Mark-Simulacrum
Copy link
Member

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.

@Mark-Simulacrum Mark-Simulacrum closed this as not planned Won't fix, can't repro, duplicate, stale Jan 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests