Module Type 'X86' conflicts with machine type 'X64'

[vikalyan]

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'

[retep998]

vsvars32.bat configures your environment to build 32-bit binaries.
The rust toolchain you're using is x86_64-pc-windows-msvc which builds 64-bit binaries.
Hence the error message telling you that there are conflicting architectures.
I recommend switching to vcvars64.bat to configure your environment.

[raindev]

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]

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]

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 x64

error: linking with `link.exe` failed: exit code: 1112
  |
  = note: "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.23.28105\\bin\\HostX86\\x86\\link.exe" "/NOLOGO" "/NXCOMPAT" "/LIBPATH:C:\\Users\\augustoproiete\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "main.main.7rcbfp3g-cgu.0.rcgu.o" "main.main.7rcbfp3g-cgu.1.rcgu.o" "main.main.7rcbfp3g-cgu.2.rcgu.o" "main.main.7rcbfp3g-cgu.3.rcgu.o" "main.main.7rcbfp3g-cgu.4.rcgu.o" "main.main.7rcbfp3g-cgu.5.rcgu.o" "/OUT:main.exe" "main.4s37gsrti678ik8u.rcgu.o" "/OPT:REF,NOICF" "/DEBUG" "/NATVIS:C:\\Users\\augustoproiete\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\etc\\intrinsic.natvis" "/NATVIS:C:\\Users\\augustoproiete\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\etc\\liballoc.natvis" "/NATVIS:C:\\Users\\augustoproiete\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\etc\\libcore.natvis" "/LIBPATH:C:\\Users\\augustoproiete\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "C:\\Users\\augustoproiete\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd-f3cd9033b21bfd69.rlib" "C:\\Users\\augustoproiete\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libpanic_unwind-7177cc63e2247a71.rlib" "C:\\Users\\augustoproiete\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libhashbrown-dc4f9fa6045181bb.rlib" "C:\\Users\\augustoproiete\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\librustc_std_workspace_alloc-b42f2443bfe541d3.rlib" "C:\\Users\\augustoproiete\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libbacktrace-727167d019576e4a.rlib" "C:\\Users\\augustoproiete\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\librustc_demangle-b116c11df52ba1e2.rlib" "C:\\Users\\augustoproiete\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libunwind-d4c5a28b76348d5c.rlib" "C:\\Users\\augustoproiete\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcfg_if-79bcbf9ce75fa48d.rlib" "C:\\Users\\augustoproiete\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liblibc-c9478dd7b586b8cc.rlib" "C:\\Users\\augustoproiete\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liballoc-c80eff7d74f3988c.rlib" "C:\\Users\\augustoproiete\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\librustc_std_workspace_core-fd0f5d5cd3b3863d.rlib" "C:\\Users\\augustoproiete\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcore-49f9f21b6d32d457.rlib" "C:\\Users\\augustoproiete\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcompiler_builtins-b32ee8ba444e5f7c.rlib" "advapi32.lib" "ws2_32.lib" "userenv.lib" "msvcrt.lib"
  = note: msvcrt.lib(chkstk.obj) : fatal error LNK1112: module machine type 'x86' conflicts with target machine type 'x64'


error: aborting due to previous error

It also left a number of temporary files on disk:

---

Running rustc or cargo from a regular command-prompt works fine, but it would be great if the message was more informative.

[mzabaluev]

In regular Windows PowerShell without path tweaks for Visual Studio, link.exe is 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]

I had the same issue when running the rust compiler on Developer Command Prompt for VS 2019:

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?

[rossy62]

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]

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:

Enter-VsDevShell -VsInstallPath "$env:VSINSTALLDIR" -DevCmdArguments "-arch=amd64 -no_logo"

[rossy62]

Yeah I dug in and discovered that the link I had read about using the Visual Studio command shell explicitly called for the X64 variant. I have so many versions of VS2019 installed, and so many command line options, murphys law dictates I would have selected the x86 variant. Once I saw the x86 vs x64 in the link errors it “pinged” something in my head. After that I was able to get where I was going. I also spent a bit more time learning about cargo manifest files, today which was helpful. Thank you! From: ChrisDenton ***@***.***> Sent: Tuesday, June 29, 2021 1:38 PM To: rust-lang/rust ***@***.***> Cc: Ross Youngblood ***@***.***>; Comment ***@***.***> Subject: Re: [rust-lang/rust] Module Type 'X86' conflicts with machine type 'X64' (#43468) CAUTION - EXTERNAL EMAIL: Do not open attachments or links unless you recognize the sender and the content is safe. 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 the find the right libraries. Or if you're adventurous you can try typing this magic in the developer powershell: Enter-VsDevShell 5f39cdd0 -DevCmdArguments "-arch=amd64 -no_logo" — You are receiving this because you commented. Reply to this email directly, view it on GitHub [github.com]<https://urldefense.com/v3/__https:/github.com/rust-lang/rust/issues/43468*issuecomment-870899410__;Iw!!GenOTVeOfQ!FmFVzau9mYn1qLjHr70cnEs1jBFs8Tg-RdGpXez1zsPDlj95vaxXd-EqmA8-J3WaiCaI8w$>, or unsubscribe [github.com]<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AO2FYYCNMWUEONE6VCBY7NTTVIVJFANCNFSM4DUIH5NA__;!!GenOTVeOfQ!FmFVzau9mYn1qLjHr70cnEs1jBFs8Tg-RdGpXez1zsPDlj95vaxXd-EqmA8-J3VSlYHIkg$>.

…

________________________________ Please note that this message may contain confidential information. If you have received this message by mistake, please inform the sender of the mistake, then delete the message from your system without making, distributing or retaining any copies of it. Although we believe that the message and any attachments are free from viruses and other errors that might affect the computer or IT system where it is received and read, the recipient opens the message at his or her own risk. We assume no responsibility for any loss or damage arising from the receipt or use of this message. When we process personal data relating to physical persons, such processing will meet the requirements of applicable data protection legislation and will be in accordance with our Privacy Policy.<https://www.teradyne.com/privacy-statement>