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: Delete grouping logic from the musl target #55659

Merged
merged 1 commit into from
Nov 9, 2018
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 0 additions & 25 deletions src/librustc_target/spec/linux_musl_base.rs
Original file line number Diff line number Diff line change
Expand Up @@ -24,31 +24,6 @@ pub fn opts() -> TargetOptions {
// argument is *not* necessary for normal builds, but it can't hurt!
base.pre_link_args.get_mut(&LinkerFlavor::Gcc).unwrap().push("-Wl,--eh-frame-hdr".to_string());

// There's a whole bunch of circular dependencies when dealing with MUSL
// unfortunately. To put this in perspective libc is statically linked to
// liblibc and libunwind is statically linked to libstd:
//
// * libcore depends on `fmod` which is in libc (transitively in liblibc).
// liblibc, however, depends on libcore.
// * compiler-rt has personality symbols that depend on libunwind, but
// libunwind is in libstd which depends on compiler-rt.
//
// Recall that linkers discard libraries and object files as much as
// possible, and with all the static linking and archives flying around with
// MUSL the linker is super aggressively stripping out objects. For example
// the first case has fmod stripped from liblibc (it's in its own object
// file) so it's not there when libcore needs it. In the second example all
// the unused symbols from libunwind are stripped (each is in its own object
// file in libstd) before we end up linking compiler-rt which depends on
// those symbols.
//
// To deal with these circular dependencies we just force the compiler to
// link everything as a group, not stripping anything out until everything
// is processed. The linker will still perform a pass to strip out object
// files but it won't do so until all objects/archives have been processed.
base.pre_link_args.get_mut(&LinkerFlavor::Gcc).unwrap().push("-Wl,-(".to_string());
base.post_link_args.insert(LinkerFlavor::Gcc, vec!["-Wl,-)".to_string()]);

// When generating a statically linked executable there's generally some
// small setup needed which is listed in these files. These are provided by
// a musl toolchain and are linked by default by the `musl-gcc` script. Note
Expand Down