Clean up default and core linker arguments

[brson]

The way we set up the default linker arguments and the linker arguments to core are quite suspicious. There are some system libraries that the compiler automatically links all crates to, it also links in rustrt by default, and - on linux only - the core library has a linkhack module for linking to yet more system libraries. I think that rustc should basically not be linking to system libraries by default - these things should be controlled by core (or whatever crate needs them).

Here are some libraries that I am pretty confident that rustc itself should not care about:

• rustrt - For the most part rustc doesn't even make any calls to rustrt now. The only exception is that libmorestack makes two calls to rustrt, but it should ultimately be calling core instead.
• rt - This is apparently related to timers and shared memory? Needed by rustrt, but not generally.
• log - Android-specific. Not sure why this is a dependency
• supc++ - Android-specific. Presumably needed by rustrt.
• gnustl_shared - Ditto
• pthread
• execinfo - FreeBSD-specific
• stdc++ - FreeBSD-specific. Presumably needed by rustrt

Libraries I'm less sure about:

• m - libmath. Unfortunately LLVM will emit calls to fmod so we seemingly have to either link to this or provide our own.
• dl - Presumably the dynamic linker. I guess we always need this

[catamorphism]

Nominating for milestone 5, production-ready

[graydon]

just a bug, removing milestone/nomination.

[pnkfelix]

Visiting for triage email from 2013-07-22. Still an issue, though I'm not sure its "just a bug" ... one might argue that projects may come to rely on implicit linkage currently being performed, and such projects will thus "break" when we remove the implicit linker arguments. (Having said that, that is a pretty easy bug for a project to fix after the fact, as long as we document which libraries start requiring explicit linkage.)

For reference: here is some data on the current link args I get on Linux, Mac, and Windows+MinGW.

For all cases, here is the two input files I used:

• /tmp/rusttmp/foo.rs:

  #[link(name="foo", vers="0.0")];
  
  pub fn two() -> int { 2 }

• /tmp/rusttmp/bar.rs:

  extern mod foo;
  
  fn main() {
      let t = foo::two();
      println(fmt!("t:%?", t));
  }

Linux:

% ( rustc --lib /tmp/rusttmp/foo.rs && RUST_LOG=rustc::back rustc -L/tmp/rusttmp /tmp/rusttmp/bar.rs 2>&1 ) | grep 'link args:'                                
rust: ~"cc link args: -L/home/pnkfelix/opt/rust/lib/rustc/x86_64-unknown-linux-gnu/lib -m64 -o /tmp/rusttmp/bar /tmp/rusttmp/bar.o -L/home/pnkfelix/opt/rust/lib/rustc/x86_64-unknown-linux-gnu/lib -lstd-c3ca5d77d81b46c1-0.7-pre -L/tmp/rusttmp -lfoo-68a2c114141ca-0.0 -lrustrt -lrt -lpthread -L/tmp/rusttmp -lrt -ldl -lm -lmorestack -lrustrt -Wl,-rpath,$ORIGIN/../../home/pnkfelix/opt/rust/lib/rustc/x86_64-unknown-linux-gnu/lib -Wl,-rpath,$ORIGIN/. -Wl,-rpath,/home/pnkfelix/opt/rust/lib/rustc/x86_64-unknown-linux-gnu/lib -Wl,-rpath,/tmp/rusttmp"        
% 

Mac OS X:

% ( rustc --lib /tmp/rusttmp/foo.rs && RUST_LOG=rustc::back rustc -L/tmp/rusttmp /tmp/rusttmp/bar.rs 2>&1 ) | grep 'link args:'
rust: ~"cc link args: -L/Users/fklock/opt/rust-dbg/lib/rustc/x86_64-apple-darwin/lib -m64 -o /tmp/rusttmp/bar /tmp/rusttmp/bar.o -L/Users/fklock/opt/rust-dbg/lib/rustc/x86_64-apple-darwin/lib -lstd-6c65cf4b443341b1-0.8-pre -L/tmp/rusttmp -lfoo-15fb3a718ea23983-0.0 -L/tmp/rusttmp -Wl,-no_compact_unwind -lmorestack -lrustrt -Wl,-rpath,@executable_path/../../Users/fklock/opt/rust-dbg/lib/rustc/x86_64-apple-darwin/lib -Wl,-rpath,@executable_path/. -Wl,-rpath,/Users/fklock/opt/rust-dbg/lib/rustc/x86_64-apple-darwin/lib -Wl,-rpath,/tmp/rusttmp"
% 

Windows+MinGW:

rust: ~"gcc link args: -Lc:\\Rust\\bin\\rustc\\i686-pc-mingw32\\bin -m32 -o rusttmp\\bar rusttmp\\bar.o -Lc:\\Rust\\bin\\rustc\\i686-pc-mingw32\\bin -lstd-6c65cf4b443341b1-0.7 -Lrusttmp -lfoo-15fb3a718ea23983-0.0 -Lrusttmp -lmorestack -lrustrt"

[alexcrichton]

There was some related discussion in #7924 about where these should go and what should be required. I think that the modes of operation (for library requirements) can fall into four main categories:

1. You use both libstd and librustrt.
2. You don't use libstd, but you use __morestack from librustrt (and get segmented stacks as well.
3. You want neither libstd nor librustrt, but you want __morestack in the sense of checking stack boundaries.
4. You don't want libstd, librustrt, or segmented stacks (__morestack) at all.

For 1, the libraries rustrt depends on could be placed in libstd. For 2 they can't, but they should still be somewhere, and for 3/4 there are no dependent libraries. I think that it's going to be pretty rare to see a use case like 2+, so would others be OK with moving the default linker arguments for rustrt into libstd/std.rs? It wouldn't be called linkhack any more, but rather something along the lines of required_external_libraries.

This may also be less of an issue (library dependencies) as more and more of rustrt gets rewritten in rust.

[catamorphism]

As per @pnkfelix 's comment, nominating this again for milestone 2, backwards-compatible.

[catamorphism]

added backwards-compat, 1.0

[alexcrichton]

This is essentially done now. The compiler itself will no longer link to any libraries by default except for libmorestack which is required by all rust programs ever. Otherwise, all runtime dependencies are now readily visible for each platform and they're all pretty much enabling various bits of functionality in libstd. If we were to remove these dependencies, we would need to remove the corresponding functions that use them in libstd (or have a compilation profile?).

For now though, these linker arguments are certainly cleaned up, and the primary focus now is moving runtime dependencies into libraries, not into the compiler itself (as mentioned in the description).