rust-lang/rust

Issues with crt2.o and dllcrt2.o from mingw.

crlf0710 opened this issue · 2 comments

crlf0710 commented

Those crt2.o and dllcrt2.o files have to match the gcc.exe used. So for example when i use win-gnu target in a msvc toolchain, I'll install my own copy of MINGW, and it should provide gcc.exe and those .o files, and i shouldn't use the rust-provided one.

So I suggest:

  1. We package these files in "rust-mingw" component instead of current "rust-std" component in win-gnu builds.
  2. Make people able to use an environment variable or something to specify where to pick these .o files in the linker command.
Amanieu commented

Could we always use the crt2.o from the host toolchain? We can get the path by invoking i686-w64-mingw32-gcc -print-file-name=crt2.o

  • 👍2
mati865 commented

That was my idea about solving it but couldn't manage to make simple fix.
Probably the best way here would be calling cc once to get the path and cache it. Since it will be the C toolchain lib dir possibility of finding conflicting Rust libs should be zero.

Edit: nowadays also msvcrt.a and mingwex.a also cause issues and the list will grow since Rust shipped libs become more out of sync from mingw-w64 headers installed on the system.
Generally every mingw-w64 lib that is shipped by Rust should be replaced with system one if it's available.