You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
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 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.
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.
"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.
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.
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
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
Activity
brson commentedon Jan 11, 2016
If this can't be fixed in the next week it should probably be reverted to rethink the migration strategy.
alexcrichton commentedon Jan 12, 2016
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 commentedon 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 commentedon Jan 12, 2016
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 commentedon 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 wrappingrustc
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 commentedon Jan 12, 2016
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 commentedon 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 commentedon 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 commentedon Jan 12, 2016
Hm detecting whether
ld
is a symlink and whether it points told.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 unfortunatelypnkfelix commentedon Jan 12, 2016
@alexcrichton
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 commentedon Jan 12, 2016
(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 commentedon Jan 12, 2016
@pnkfelix perhaps yeah, but at that point I'd probably be more in favor of just disabling by default.
19 remaining items
sanmai-NL commentedon Jun 1, 2017
@bstrie: small update, the release date for Debian Stretch has been set at 17 June 2017.
SimonSapin commentedon Nov 27, 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
SimonSapin commentedon Nov 27, 2017
Or is it @rust-lang/dev-tools ?
glandium commentedon 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 commentedon Apr 3, 2018
Even if some people and companies want to keep supporting Wheezy, does that mean that recent rustc versions need to do the same?
glandium commentedon Apr 3, 2018
Well, Firefox builds are done on Debian Wheezy at the moment...
cargo build
rebuilds the world after./mach build
, and vice versa. servo/servo#20489workingjubilee commentedon Sep 5, 2020
It's 2020.

It's time for
Mark-Simulacrum commentedon Jan 7, 2024
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.