-Z lto fails to compile in Windows

[lifthrasiir]

This simple code:

fn main() { println!("hi"); }

fails to compile with rustc foo.rs -Z lto in Windows with MinGW:

> rustc foo.rs -Z lto
error: linking with `gcc` failed: exit code: 1
note: gcc arguments: '-m32' '-L<rust>\rustlib\i686-pc-mingw32\lib' '-o' 'foo' 'foo.o' '-shared-libgcc' '-LC:\Users\<username>\.rust' '-LC:\Users\<username>' '-lgcc_s' '-lws2_32' '-lpsapi' '-liphlpapi' '-lmorestack' '-lcompiler-rt'
note: Cannot export __rust_crate_map_toplevel: symbol not found
foo.o:(.text+0x244f3): undefined reference to `rust_try'
foo.o:(.text+0x80653): undefined reference to `rust_valgrind_stack_deregister'
foo.o:(.text+0x82c36): undefined reference to `rust_swap_registers'
(... omitted ...)
<mingw>/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: foo.o: bad reloc address 0x4 in section `.data'
collect2.exe: error: ld returned 1 exit status

error: aborting due to previous error

Undefined references are C symbols from libstd, libgreen and librustuv, which rlibs are not linked against. Tested with the unofficial Windows nightly 0.10-pre (cae5999 2014-02-18 19:26:50 -0800) but I guess this issue is not really related to the nightlies.

[huonw]

cc @alexcrichton

[lifthrasiir]

I have investigated a bit more about this issue. It turns out that there are really two independent issues exist:

1. The linker arguments do not contain the temporary rlibs used to link against non-Rust static dependencies within rlibs. Rustc does generate the temporary rlibs, but fails to properly parse the output of ar t command resulting in a stray \r in each entries. (Oops!)
2. Trans generates the symbol _rust_crate_map_toplevel with a weak linkage, but the LTO pass strips it and thus the linker fails to export it. I don't really know what is going on here (especially the differences among _rust_crate_map_toplevel, __rust_crate_map_toplevel and ___rust_crate_map_toplevel) but @klutzy told me that these differences are important enough that the compilation fails.

[alexcrichton]

Is the output of ar t delimited by \r\n or only \r? That would indeed cause many bugs with LTO if the output isn't delimiting lines with exactly \n.

[lifthrasiir]

@alexcrichton It is delimited by \r\n. Maybe we should just trim all preceding/trailing whitespaces from the output.

[alexcrichton]

#12475 should fix some of the problems, but the crate map is a little disturbing...

[klutzy]

Fixed by #13117: no crate map anymore!

[alexcrichton]

Oh man, how convenient!