add a RUSTLINKFLAGS environment variable

[froydnj]

The motivating example here is when you want to have development and release profiles with lto = false, because LTO is so expensive. Why not put lto = true in your release profile? Because the release profile might not be used for releases, per se; it might be used for people doing local development, and they don't want to bear the burden of compiling with LTO all the time. They want to compile with optimization on so at least their performance measurements are not completely out of whack.

But you do want to compile with LTO at certain times: when you're doing a formal release of your software, for instance. It would be convenient to turn LTO on via -C lto in RUSTFLAGS...but -C lto isn't valid for all places where RUSTFLAGS would be passed.

Hence the request for a RUSTLINKFLAGS or similar that would specify flags to be used in the final link of a binary artifact.

This could be made somewhat superfluous by #2007, where we could specify another profile for "release releases", but it might still be handy to have for flags that can't be injected via Cargo.toml.

/cc @luser @glandium

[alexcrichton]

This is a pressing enough problem that I don't think it's worth waiting for custom profiles (as those may take awhile to get underway).

Do you have a gist of the errors you were seeing with RUSTFLAGS=-Clto? I think the "best" solution here may be to just fix the compiler to stop complaining about -Clto on things like dylibs/cdylibs, seeing how -Clto is just an "optimization preference" it may make sense to just bypass it in those situations.

Failing that though I may prefer to take a more targeted route for now where we just allow LTO (e.g. CARGO_BUILD_LTO=1) rather than arbitrary flags at the "link" stage. That'd solve the problem for now and still leave room for the final solution (custom profiles) I believe. Were you thinking of solving other problems with RUSTLINKFLAGS though? If so seems like not the worst feature to add!

[glandium]

A random thought I just had is that an argument to cargo that allows to override what is set in Cargo.toml would go a long way (similarly to e.g. hg or git allowing to set/override their config from the command line). Something like:

cargo build -c profile.release.lto=false

[alexcrichton]

Hm yeah an excellent point! It's worth noting though that cargo's system configuration is pretty different than Cargo.toml configuration, but I think we should make an exception for profiles which really should be build time configuration

[froydnj]

Do you have a gist of the errors you were seeing with RUSTFLAGS=-Clto? I think the "best" solution here may be to just fix the compiler to stop complaining about -Clto on things like dylibs/cdylibs, seeing how -Clto is just an "optimization preference" it may make sense to just bypass it in those situations.

The error when lto = false in Cargo.toml and RUSTFLAGS="-C lto" is:

error: lto can only be run for executables, cdylibs and static library outputs

which I think fits in with your suggestion of dropping the warning?

Were you thinking of solving other problems with RUSTLINKFLAGS though?

I can't think of any problems at the moment! I like the CARGO_BUILD_LTO=1 idea and/or @glandium's command-line configuration. @glandium's command-line configuration stuff seems less likely to cause problems at a later date and more generally flexible/useful anyway. (I have some reservations about exposing that much build configuration to the command-line, but I suppose it's not wildly different from what you already have with --features.) We'd want that flag to be a global flag to cargo, though, and not cargo build-specific, yes?

[luser]

If we're going to fix this in a simple way, making rustc not warn about -C lto for rlib compiles seems like the simplest fix. For a better long-term solution I think custom profiles is the best way to go, personally. Being able to override individual profile bits on the commandline is a neat idea as well, though, and I could see either of them being a reasonable solution.

[glandium]

The problem with custom profiles is that they're quadratic. You may need variants for debug and non-debug. Opt vs. no-opt. LTO vs no-LTO, abort panics vs. unwind, etc.

[alexcrichton]

@froydnj

which I think fits in with your suggestion of dropping the warning?

Ah yes, indeed! In retrospect I think at most a warning should be emitted in that case and in reality we should just ignore it in the compiler, doing a 'best effort' thing when possible and otherwise ignoring it for things like rlibs.

I can't think of any problems at the moment! I like the CARGO_BUILD_LTO=1 idea and/or @glandium's command-line configuration. @glandium's command-line configuration stuff seems less likely to cause problems at a later date and more generally flexible/useful anyway.

Indeed! I'll comment on the PR wrt this strategy.

[cgwalters]

Cross-linking https://bugzilla.mozilla.org/show_bug.cgi?id=1386371 here

[epage]

If I'm understanding correctly, there is a somewhat related RFC at rust-lang/rfcs#3310

[epage]

See also

• Tracking Issue: Exposing RUSTFLAGS in cargo #12739
• Per-user compiled artifact cache #5931
• Reconsider RUSTFLAGS artifact caching. #8716

[epage]

Also, if we expose more rustflags in Cargo-native ways (#12739), then Cargo can then decide to only fingerprint and pass the flag to final artifacts.

[epage]

btw LTO is not a great case for this as we now do change dependencies build based on lto as discussed in #3244.