Split the /opt:ref,icf arguments to i686-pc-windows-msvc linker

[alexchandel]

Currently rustc passes /opt:ref,icf to the linker for the i686-pc-windows-msvc target, even when -C opt-level=0 is explicitly passed. LLD's link.exe flavor doesn't support comma-separated arguments, and would require /opt:ref /opt:icf. rustc should pass these separately.

Moreover, rustc needs provide a way to stop them from being passed at all, as I explicitly specified zero optimiations, and didn't pass -C lto.

[retep998]

Is there an issue for LLD's inability to handle comma-separated arguments in LLVM's bug tracker yet?

[alexchandel]

There is, https://llvm.org/bugs/show_bug.cgi?id=25228. Apparently commas are sparsely documented.

[luqmana]

Fix for lld accepting comma-separated arguments committed upstream: r250728.

[alexchandel]

@retep998 As of that fix, assuming lld is installed and the link.exe -> lld symlink exists, and the Win10 SDK libraries and VC6 libraries exist at i686-pc-windows-msvc-w10/lib and $HOME/i686-pc-windows-msvc-vc6/lib, then the following: LIB="$HOME/i686-pc-windows-msvc-w10/lib;$HOME/i686-pc-windows-msvc-vc6/lib" rustc --target i686-pc-windows-msvc -O -C lto test.rs produces a working Windows executable on OS X x86_64. However, compiling with optimizations still misses symbols:

note: libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _roundf
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _truncf
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _fmaf
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _exp2f
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _log2f
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _nextafterf
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _fmaxf
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _fminf
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _fdimf
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _cbrtf
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: __hypotf
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _expm1f
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _log1pf
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _round
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _trunc
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _fma
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _exp2
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _log2
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _nextafter
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _fmax
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _fmin
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _fdim
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _cbrt
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _expm1
libstd-10cbabc2.rlib(std-10cbabc2.0.o): undefined symbol: _log1p
Link failed

Just closing.

[retep998]

@alexchandel That looks like you're simply forgetting to link in msvcrt.

[alexchandel]

@retep998 Except these are only math functions. Clearly msvcrt's entry point is present, as are the memory functions. More importantly I'm not calling the linker: rustc is. The link arguments is uses are "link.exe" "/NOLOGO" "/NXCOMPAT" "/LIBPATH:/usr/local/lib/rustlib/i686-pc-windows-msvc/lib" "test.0.o" "/OUT:test.exe" "/OPT:REF,ICF" "/DEBUG" "/LIBPATH:/usr/local/lib/rustlib/i686-pc-windows-msvc/lib" "/LIBPATH:/Users/alex/Desktop/.rust/lib/i686-pc-windows-msvc" "/LIBPATH:/Users/alex/Desktop/lib/i686-pc-windows-msvc" "ws2_32.lib" "userenv.lib" "advapi32.lib" "kernel32.lib" "shell32.lib" "msvcrt.lib" "compiler-rt.lib".

Also, this only happens when -O -C lto are not passed.

[retep998]

@alexchandel Are you still using the old VC6 msvcrt? It might not have those specific symbols.

[alexchandel]

@retep998 That is probably it. It's possible that nextafter is only supported post-VC2010, which is frightening. This lingering issue is a reason to leave msvcrt's math functions for openlibm's though.

Also, it would be nice to have just i686-pc-windows-msvc-w10/lib, and not LIB="$HOME/i686-pc-windows-msvc-w10/lib;$HOME/i686-pc-windows-msvc-ucrt10/lib;$HOME/i686-pc-windows-msvc-vc14/lib" when trying to compile with a newer msvcrt.

[9prady9]

Is this issue fixed in nightly(1.6) or beta(1.5) ? Is there any temporary work around for this with 1.4 stable release ?

[alexchandel]

@9prady9 rustc still doesn't split the arguments, but LLD's head can handle them now. However, we are still relying on an undocumented feature.

The other tangential issue discussed still exists, in that Rust's standard library isn't compatible with VC6's msvcrt, but requires VS 2013's. That could be resolved by rolling our own libm, which also solves many other issues, as proposed in rust-lang/rfcs#711.