rust-1.8.0-x86_64-pc-windows-gnu can't cross-compiling for windows 32bit

[zoumi]

I have both 32bit gcc.exe and 64bit gcc.exe in the dir where "rust-1.8.0-x86_64-pc-windows-gnu" installed.The directory structre is showed below.

E:\PROGRAM FILES\RUST STABLE GNU 1.8\LIB
└─rustlib
├─i686-pc-windows-gnu
│ ├─bin
│ │ ar.exe
│ │ dlltool.exe
│ │ gcc.exe
│ │ ld.exe
│ └─lib
└─x86_64-pc-windows-gnu
├─bin
│ ar.exe
│ dlltool.exe
│ gcc.exe
│ ld.exe
└─lib

I can use the 32bit gcc.exe compile for both 32bit and 64bit .exe file.
But the 64b bit gcc.exe can only build for 64bit .exe file.
When I use 64b bit gcc.exe compile for 32bit .exe file I get this error:

warning: the option Z is is unstable and should only be used on the nightly compiler, but it is currently accepted for backwards compatibility; this will soon change, see issue #31847 for more details
error: linking with E:\Program Files\Rust stable GNU 1.8\lib\rustlib\x86_64-pc-windows-gnu\bin\gcc.exe failed: exit code: 1
note: "E:\Program Files\Rust stable GNU 1.8\lib\rustlib\x86_64-pc-windows-gnu\bin\gcc.exe" "-Wl,--enable-long-section-names" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-nostdlib" "-Wl,--large-address-aware" "E:\Program Files\Rust stable GNU 1.8\lib\rustlib\i686-pc-windows-gnu\lib\crt2.o" "E:\Program Files\Rust stable GNU 1.8\lib\rustlib\i686-pc-windows-gnu\lib\rsbegin.o" "-L" "E:\Program Files\Rust stable GNU 1.8\lib\rustlib\i686-pc-windows-gnu\lib" "main.0.o" "-o" "main.exe" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "E:\Program Files\Rust stable GNU 1.8\lib\rustlib\i686-pc-windows-gnu\lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "E:\Program Files\Rust stable GNU 1.8\lib\rustlib\i686-pc-windows-gnu\lib\libstd-4fda350b.rlib" "E:\Program Files\Rust stable GNU 1.8\lib\rustlib\i686-pc-windows-gnu\lib\libcollections-4fda350b.rlib" "E:\Program Files\Rust stable GNU 1.8\lib\rustlib\i686-pc-windows-gnu\lib\librustc_unicode-4fda350b.rlib" "E:\Program Files\Rust stable GNU 1.8\lib\rustlib\i686-pc-windows-gnu\lib\librand-4fda350b.rlib" "E:\Program Files\Rust stable GNU 1.8\lib\rustlib\i686-pc-windows-gnu\lib\liballoc-4fda350b.rlib" "E:\Program Files\Rust stable GNU 1.8\lib\rustlib\i686-pc-windows-gnu\lib\liballoc_system-4fda350b.rlib" "E:\Program Files\Rust stable GNU 1.8\lib\rustlib\i686-pc-windows-gnu\lib\liblibc-4fda350b.rlib" "E:\Program Files\Rust stable GNU 1.8\lib\rustlib\i686-pc-windows-gnu\lib\libcore-4fda350b.rlib" "-l" "gcc_eh" "-l" "gcc_eh" "-l" "ws2_32" "-l" "userenv" "-l" "shell32" "-l" "advapi32" "-l" "compiler-rt" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-luser32" "-lkernel32" "E:\Program Files\Rust stable GNU 1.8\lib\rustlib\i686-pc-windows-gnu\lib\rsend.o"
note: ld: unrecognized option '--large-address-aware'
ld: use the --help option for usage information
error: aborting due to previous error

[alexcrichton]

Thanks for the report! Unfortunately for the MinGW compilers you can't use them to cross compile, so if you want to cross from 32 to 64 you have to do so in a 64 environment. Could you explain in detail though the steps needed to reproduce this? It's somewhat unclear to me how you got the directory structure so far.

[retep998]

The weird part in my opinion is that it is calling E:\Program Files\Rust stable GNU 1.8\lib\rustlib\x86_64-pc-windows-gnu\bin\gcc.exe, but passing stuff such as E:\Program Files\Rust stable GNU 1.8\lib\rustlib\i686-pc-windows-gnu\lib\rsbegin.o. It is using the bundled x86_64 binaries for the i686 target.

I'd test this but I can't get rustup.rs to install additional targets.

[zoumi]

@alexcrichton
1,Install rust-1.8.0-x86_64-pc-windows-gnu.msi
2,Install rust-1.8.0-i686-pc-windows-gnu.msi
3,Copy i686's rustlib to x86_64' rustlib
4,Uinstall rust-1.8.0-i686-pc-windows-gnu.msi
5,Repare rust-1.8.0-x86_64-pc-windows-gnu.msi

[alexcrichton]

Ah yes in that case this is intended behavior. The compiler only assumes that it can run executables for its own platform, which in this case is x86_64-pc-windows-gnu. That means that the compiler is running a 64-bit mingw gcc trying to generate a 32-bit executable. The mingw gcc builds, however, do not support this.

You'll probably want to uncheck the "install native gcc component" during the installer and then you can cross compile by ensuring that the right gcc is in your PATH whenever you cross compile. I'd also recommend using MSVC as the cross compilation story is better there as we can find the cross-compiler for you most of the time.