Repository navigation
Module Type 'X86' conflicts with machine type 'X64' #43468
Description
Using a custom Windows container that contains Visual Studio 2015 Enterprise Update 3 full installation, Windows 10 SDK full installation on a X64 base OS.
Compiling a simple HelloWorld.rs program with no dependencies etc.
I get the following error.
Is there a specific flag I have to pass in? I did run the vsvars32.bat batch file to set the appropriate environment variables for VC.
error: linking with `link.exe` failed: exit code: 1112
|
= note: "C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\BIN\\link.exe" "/NOLOGO" "/NXCOMPAT" "/LIBPATH:C:\\Program Files\\Rust stable MSVC 1.18\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "HelloWorld.0.o" "/OUT:HelloWorld.exe" "/OPT:REF,NOICF" "/DEBUG" "/LIBPATH:C:\\Program Files\\Rust stable MSVC 1.18\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "C:\\Program Files\\Rust stable MSVC 1.18\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd-0a78323911070f99.rlib" "C:\\Program Files\\Rust stable MSVC 1.18\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\librand-c279a51d66700350.rlib" "C:\\Program Files\\Rust stable MSVC 1.18\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcollections-d7bf31a4ca1ea637.rlib" "C:\\Program Files\\Rust stable MSVC 1.18\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd_unicode-d367c3ba0db49600.rlib" "C:\\Program Files\\Rust stable MSVC 1.18\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libpanic_unwind-2d4bf02140c11dcb.rlib" "C:\\Program Files\\Rust stable MSVC 1.18\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libunwind-add7a84d7e82d084.rlib" "C:\\Program Files\\Rust stable MSVC 1.18\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liblibc-84688accbc86d6b7.rlib" "C:\\Program Files\\Rust stable MSVC 1.18\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liballoc-fe2e68b21f0bdd7a.rlib" "C:\\Program Files\\Rust stable MSVC 1.18\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liballoc_system-7fc0381594c93f56.rlib" "C:\\Program Files\\Rust stable MSVC 1.18\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcore-ea9d77e7c23fe65c.rlib" "C:\\Program Files\\Rust stable MSVC 1.18\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcompiler_builtins-91b619d34dd1f5aa.rlib" "advapi32.lib" "ws2_32.lib" "userenv.lib" "shell32.lib" "msvcrt.lib"
= note: msvcrt.lib(chkstk.obj) : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
Activity
retep998 commentedon Jul 25, 2017
vsvars32.batconfigures your environment to build 32-bit binaries.The rust toolchain you're using is
x86_64-pc-windows-msvcwhich builds 64-bit binaries.Hence the error message telling you that there are conflicting architectures.
I recommend switching to
vcvars64.batto configure your environment.raindev commentedon Jul 5, 2019
This is not a Rust bug per se. Maybe the situation can be detected by cargo to produce a better error message. Having some sort of FAQ for common pitfalls like this in the installation section of the website might be a good idea as well.
pkeir commentedon Nov 26, 2019
Some VS Code C++ tutorials encourage starting "code" from the developer command prompt. I faced the LNK1112 issue, and it turned out I had accidentally started VS Code using the 32-bit developer command prompt (alas still the default). Starting VS Code from a 64-bit prompt, or simply from the Windows Start Menu, removed the issue.
augustoproiete commentedon Dec 5, 2019
I had the same issue when running the rust compiler on Developer Command Prompt for VS 2019:
rustc 1.39.0 (4560ea788 2019-11-04):Windows 10 x64It also left a number of temporary files on disk:
Running
rustcorcargofrom a regular command-prompt works fine, but it would be great if the message was more informative.mzabaluev commentedon Feb 15, 2020
In regular Windows PowerShell without path tweaks for Visual Studio,
link.exeis not found in the command path, so cargo appears to magically discover the absolute path name in the x64 tools directory, which is the correct one. The host architecture of the shell does not affect this behavior.Unfortunately, the launchers named Developer PowerShell and Developer Command Prompt for VS 2019 set up the command path for x86 tools. Perhaps it would be better for cargo to ignore the PATH-located executable on Windows if the registry-resolved tools directory appropriate for the target platform contains the executable file.
Remco-Schoeman commentedon May 21, 2021
I am a "installed Rust today to try it out" user but also .Net veteran, which is why this same issue tripped me up today I guess...
Is it possible to add a note about this Developer Command Prompt path issue to the https://www.rust-lang.org/tools/install Notes - Configuring the PATH environment variable - section?
Rollup merge of rust-lang#85649 - ChrisDenton:update-cc, r=matthewjasper
Rollup merge of rust-lang#85649 - ChrisDenton:update-cc, r=matthewjasper
Rollup merge of rust-lang#85649 - ChrisDenton:update-cc, r=matthewjasper
rossy62 commentedon Jun 29, 2021
I had the same problem doing a cbindgen install today. I'm just past the "hello world" stage, and preparing to use RUST to build libraries/DLLs that I would call from C/C++ code.
I started using the Visual Studio developer powershell and this seems to be OK for some tasks. I don't know what web page suggested I do this to get X64 environment.
At any rate doing a cargo install cbindgen fails miserably if your powershell is configured by Microsoft. I just dropped to the generic powershell, and the download/build/install for cbindgen worked flawlessly. (or so it appears)...
ChrisDenton commentedon Jun 29, 2021
Hopefully this should be fixed in the next version of Rust (1.54).
Usually Rust can automatically find the right libraries to use but the problem here is that the developer powershell, by default, puts the x86 libraries and linker in environment variables where as Rust is compiling for x64. So Rust needs some way to know they're wrong and that it should go looking for the right ones. Which is what it should do in the future.
In the meantime, as you say, you can use the generic powershell. Rust will then go find the right libraries. Or if you're adventurous you can try typing this magic in the developer powershell:
rossy62 commentedon Jun 29, 2021