mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Rollup merge of #55659 - alexcrichton:musl-no-group, r=michaelwoerister

Browse Source 
rustc: Delete grouping logic from the musl target

This commit deletes the injection of `-(` and `-)` options to the linker
for the musl targets. This actually causes problems today on nightly if
you execute:

    $ echo 'fn main() {}' >> foo.rs
    $ rustc --target x86_64-unknown-linux-musl -C panic=abort

you get a linker error about "cannot nest groups". This comes about
because rustc injects its own `--start-group` and `--end-group`
variables which clash with the outer `-(` and `-)` variables. It's not
entirely clear to me why this doesn't affect the musl target by default
(in `-C panic=unwind` mode).

The compiler's own injection of `--start-group` and `--end-group` should
solve the issues mentioned in the comment for injecting `-(` and `-)` as
well.
This commit is contained in:
Mark Rousskov 2018-11-08 18:14:53 -07:00 committed by GitHub
commit 602a8b400f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 0 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
src/librustc_target/spec/linux_musl_base.rs
View File

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