Repository navigation
Issues with crt2.o and dllcrt2.o from mingw. #53454
Description
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:
- We package these files in "rust-mingw" component instead of current "rust-std" component in win-gnu builds.
- Make people able to use an environment variable or something to specify where to pick these .o files in the linker command.
Reacted by Tarragon, Screwtapello, Roy Ivy III, Dana Marcuse, ૮༼⚆︿⚆༽つ, Marcin (Miriam) Mielniczuk, DCjanus, Kane Green, Michele Federici, Félix C. Morency and 5 more
Activity
Disable build matrix for mingw
CI: fix and improve AppVeyor CI
Amanieu commentedon Oct 29, 2019
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.omati865 commentedon Oct 29, 2019
That was my idea about solving it but couldn't manage to make simple fix.
Probably the best way here would be calling
cconce 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.
Auto merge of #67429 - mati865:mingw-ultimate-fix, r=<try>
Auto merge of #67429 - mati865:mingw-ultimate-fix, r=alexcrichton
CICD: Build: Enable *-pc-windows-gnu builds again (with 'stable')
CICD: Build: Enable x86_64-pc-windows-gnu again
CICD: Build: Enable x86_64-pc-windows-gnu again