rustc should attempt to use the gold linker by default, but this breaks Debian Wheezy because of obsolete gcc

[brson]

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]

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

[alexcrichton]

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]

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

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]

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]

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]

"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]

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]

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]

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

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

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

[vadimcn]

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

[birkenfeld]

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

[alexcrichton]

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

[bstrie]

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

[bstrie]

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]

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]

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]

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.

[sanmai-NL]

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

[SimonSapin]

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]

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

[glandium]

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]

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

[glandium]

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