204

我正在使用 CUDA (VC++, Visual Studio 2008sp1) 来调试 FEM 程序。由于cuda的不足，程序只能运行在Win32平台上。我认为链接的库文件都是在x86平台上编译的，但是当我编译它时，我收到错误消息“致命错误LNK1112：模块机器类型'x64'与目标机器类型'X86'冲突”。

我曾尝试将平台转换为 x64，但没有成功。请告诉我：什么是“模块机器类型”，什么是“目标机器类型”？我怎样才能克服它？

4

28 回答 28

281

我写了一篇关于这个的博客文章，因为我遇到了这个令人抓狂的问题，最后把我的系统拉回了工作状态。

这些是要检查的内容，按以下顺序：

  1. 检查链接器设置中的属性选项：属性 > 配置属性 > 链接器 > 高级 > 目标机器。如果您的目标是 64 位构建，请选择 MachineX64，如果您要构建 32 位构建，请选择 MachineX86。

  2. 从 Visual Studio 的主菜单中选择构建 > 配置管理器。确保您的项目指定了正确的平台。可以将 IDE 设置为构建 x64，但可以将解决方案中的单个项目设置为以 win32 为目标。所以，是的，视觉工作室留下了很多绳子来吊死自己，但这就是生活。

  3. 检查您的库文件，它们确实属于所针对的平台类型。这可以通过使用您的 Visual Studio VC\bin 目录中的 dumpbin.exe 来使用。使用 -headers 选项转储所有功能。查找每个功能的机器条目。如果它是 64 位版本，它应该包括 x64。

  4. 在 Visual Studio 中，从主菜单中选择工具 > 选项。选择项目和解决方案 > VC++ 目录。从平台下拉列表中选择 x64。确保第一个条目是：$(VCInstallDir)\bin\x86_amd64后跟$(VCInstallDir)\bin。

一旦我完成了第 4 步，一切都再次为我工作。问题是我在我想要编译为 64 位目标的所有项目中都遇到了这个问题。

于 2010-12-06T07:06:19.930 回答
165

除了C Johnson列表之外，我还要添加以下几点：

签入 Visual Studio：
项目属性 -> 配置属性 -> 链接器 -> 命令行。

“附加选项”不应包含/machine:X86

我有这样的密钥，由 CMake 输出生成：CMake生成 x86 项目，然后我在 Visual Studio 2010 中添加了 x64 平台- 除了单独Configuration Manager指定的链接器命令行之外，所有内容都为新平台创建得很好。/machine:X86

于 2013-04-08T22:35:17.317 回答
55

当我尝试将 X64 构建添加到从 VS2003 转换的项目时，我在 VS2008 中遇到了同样的问题。

我查看了在 Google 上搜索此错误时发现的所有内容（目标机、VC++ 目录、DUMPBIN ......），一切看起来都很好。

最后，我创建了一个新的测试项目并进行了相同的更改，并且似乎可以正常工作。

在 vcproj 文件之间进行比较揭示了问题....

我转换后的项目将 /MACHINE:i386 设置为 Linker->Command Line 下的附加选项集。因此，设置了两个 /MACHINE 选项（x64 和 i386），另外一个优先。

删除它并在 Linker->Advanced->Target Machine 下正确设置它使问题消失了。

于 2012-01-13T08:28:22.803 回答
26

所有项目设置似乎都很完美，但我仍然收到错误。查看.vcxproj文件并搜索“x86”发现了问题：

<Lib>
  <AdditionalOptions> /machine:X86 %(AdditionalOptions)</AdditionalOptions>
</Lib>

快速搜索/替换所有事件（十个单独的文件设置）解决了这个问题。

于 2017-03-13T20:20:40.013 回答
13

当您链接 x86（即目标机器类型）时，您可能有一个针对 x64（即模块机器类型）的 .OBJ 或 .LIB 文件。

在 .OBJ 文件上使用 DUMPBIN /HEADERS 并检查 FILE HEADER VALUES 块中的机器条目。

于 2010-08-25T08:01:55.030 回答
13

由于问题是由于编译和目标机器规格（x86和x64）的差异造成的，请按照以下步骤操作：

  1. 打开要配置的 C++ 项目。
  2. 选择配置管理器按钮以打开配置管理器对话框。
  3. 在 Active Solution Platform 下拉列表中，选择选项以打开 New Solution Platform 对话框。
  4. 在类型或选择新平台下拉列表中，选择 64 位平台。

它解决了我的问题。

于 2014-05-13T20:55:24.873 回答
7

在 Visual Studio 2012 +/- 中，“配置属性”的属性页。链接器。“命令行”包含一个标有“附加选项”的框。如果您正在构建 x64，请确保该框不包含 /MACHINE： I386. 我的项目做了，它产生了有问题的错误。

于 2014-11-15T04:59:40.277 回答
4

我在构建 QT 时遇到了这个问题。我在某处读到的说明建议我使用 VS 命令提示符配置 nmake。

我选择了 x64 命令提示符并毫不费力地执行了配置。当我尝试nmake时，它给出了这个错误。

我认为某些组件是为 32 位预先构建的。该错误甚至报告了哪些模块是为 x86 构建的。

我使用了 32 位默认的 VS 命令提示符，它工作正常。

于 2013-08-29T09:52:25.200 回答
3 
"project property - CUDA Runtime API - GPU - NVCC Compilation Type"

设置 64 位编译选项-m64 -cubin

提示在编译日志中。像这样：

nvcc.exe ~~~~~~ -machine 32 -ccbin ~~~~~

那"-machine 32"是问题。

首先设置 64bit 编译选项，然后重新设置混合编译选项。然后你可以看到成功。

于 2013-07-25T10:34:37.493 回答
3

在 Visual Studio 2013 中，

1）检查项目属性页/配置属性/链接器/所有选项并更正所有未配置的机器和目录。

2）检查项目属性页/配置属性/链接器/输入并更正所有未配置的目录。

参见示例 1)

于 2014-01-03T17:43:09.323 回答
2

如果您的解决方案有 lib 项目，请在 Property->Librarian->General 中检查 Target Machine 属性

于 2013-10-28T09:47:50.797 回答
2

vcxproj 文件可能包含 'MACHINE:i386' 使用编辑器编辑 vcxproj 文件。去掉它 ！

于 2017-09-29T02:00:32.247 回答
1

就我而言，设置环境变量PROCESSOR_ARCHITECTURE来AMD64 解决问题。

https://social.msdn.microsoft.com/Forums/en-US/f9303904-81ce-405d-85b3-b66d97e49971

于 2021-05-13T22:37:09.703 回答
0

除了 Jhonson 的列表，还要检查库的文件夹

在 Visual Studio 中，从主菜单中选择工具 > 选项。选择项目和解决方案 > VC++ 目录。从平台下拉列表中选择 x64。

$(VCInstallDir)lib\AMD64;
$(VCInstallDir)atlmfc\lib\amd64;
$(WindowsSdkDir)lib\x64;
于 2014-01-13T15:55:52.483 回答
0

我通过在 Visual Studio 2013 中将 Win32 更改为 *64 解决了这个问题。

于 2018-08-08T09:44:58.130 回答
0

Many good suggestions above.

Also if you are trying to build in x86 Win32:

Make sure that any libraries you link to in Program Files(x86) are actually x86 libraries because they are not necessarily...

For example a lib file I linked to in C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\SDK threw that error, eventually I found an x86 version of it in C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\um\x86 and everything worked fine.

于 2020-01-09T15:28:01.500 回答
0

属性-> 配置管理器-> ActiveSolutionPlatform 。在这里选择 x64 。仅此而已。

它应该处理所有依赖项，并且编译应该可以顺利进行

于 2022-01-19T06:28:56.803 回答
0

首先尝试以下操作： 1. 转到配置管理器并创建一个新的 x64（如果它不存在）。2.选择x64解决方案。3.进入项目属性，然后链接器->高级选择x64机器。4. 现在重建解决方案。

如果您仍然收到相同的错误。尝试干净的解决方案，然后再次重建并打开 Visual Studio，您将获得最近打开的项目列表，右键单击该项目并将其从那里删除。现在转到解决方案并再次重新打开解决方案。

于 2016-06-02T11:05:42.473 回答
0

我的目标是 C 语言的 x64 Windows 10 文本模式 DOSBox 应用程序。使用“Visual Studio 2019 Community”通过DOS提示符“nmake -f makefile”进行编译。错误是相似的，但在相反的一面：

fatal error LNK1112: module machine type 'x32' conflicts with target machine type 'X64'

在另一台电脑上用VC++ 2010编译就可以了。但是“Visual Studio 2019 Community”在这台计算机上失败了。所以我的设置是正确的，以上所有答案都不起作用。

我想与您分享解决方案是这样的 make.bat：

call "c:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64.bat" 
nmake -f makefile

你会发现还有很多其他的vcvarsxxxx.bat，只有这一个字。

于 2020-10-10T00:01:22.800 回答
0

这是一个非常令人沮丧和烦人的问题，但一旦你理解了它，它就很简单：你有一些元素在你构建一个架构类型（在你的情况下是 x64）尽管它是另一种类型的目标（比如 x86 ）。

您可以通过查看导致崩溃的 obj 文件来剖析问题的根源并开始在那里寻找问题。每个 obj 都会有一个源代码模拟：在 cpp、c、asm 等中。可能有一些特殊的构建事件围绕它使用了错误的工具。在属性表中检查。

在浏览 C Johnson 的待办事项清单之前，我会先看看那里。

于 2017-01-28T21:34:12.960 回答
0

这发生在我今天，因为我在 x86 模式下添加了一个库目录，并意外删除了继承的目录，改为硬编码。然后切换到 x64 后，我的 VC++ 目录仍然显示：

“...;$(VC_LibraryPath_x86);$(WindowsSDK_LibraryPath_x86);”

而不是_x64。

于 2015-10-17T18:41:58.787 回答
0

我正在使用 CMake，然后添加了一个 win32 配置。属性页显示x86，但实际上在文本编辑器中打开 vcxproj 文件时它是 x64！手动更改为 x86 解决了这个问题。

于 2016-01-31T17:44:39.597 回答
-1

模块机器类型是您正在编译的机器，目标机器类型是您正在为其构建二进制文件的架构 x86 或 x64。

于 2013-10-16T04:40:32.690 回答
-1

如果您的项目在项目属性 -> 配置属性 -> 常规中设置为具有相同的中间目录，也可能会发生此问题

于 2015-06-06T17:03:30.957 回答
-1

当我将我的 VS2008 解决方案转换为 VS2010 并将 win32 配置更改为 X64 时，这发生在我身上，在我的旧解决方案中，我有 mfcs90d.lib（配置->链接器->输入->附加依赖项），因为我正在使用 VS010 我刚刚检查过在 VS2010 文件夹中，它是 mfcs100d.lib，所以我在（配置->链接器->输入->附加依赖项）中将 mfcs90d.lib 更改为 mfcs100d.lib，它工作正常。

于 2017-03-02T09:03:50.977 回答
-1

对于那些使用 QT Creator 的人来说，问题是相同的（如@c-johnson 所述）。确保套件中 MSVC 的编译器设置设置为 x86，如下所示。

MSVC x86 编译器的 QT Creator Kit 设置

于 2019-07-09T15:41:59.917 回答
-1

对于某些使用命令提示符（dos 提示符）的人，这可能会有所帮助：

call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" --help
Error in script usage. The correct usage is:
    "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" [option]
  or
    "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" [option] store
  or
    "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" [option] [version number]
  or
    "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" [option] store [version number]
where [option] is: x86 | amd64 | arm | x86_amd64 | x86_arm | amd64_x86 | amd64_arm
where [version number] is either the full Windows 10 SDK version number or "8.1" to use the windows 8.1 SDK
:
The store parameter sets environment variables to support
  store (rather than desktop) development.
:
For example:
    "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86_amd64
    "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86_arm store
    "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86_amd64 10.0.10240.0
    "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86_arm store 10.0.10240.0
    "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x64 8.1
    "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x64 store 8.1
:
Please make sure either Visual Studio or C++ Build SKU is installed.

另外，如果您这样做：

CL "%1%2%3" /EHsc /link user32.lib Gdi32.lib Winmm.lib comctl32.lib *.obj /SUBSYSTEM:CONSOLE /MACHINE:x86

你必须先删除*.obj ；避免将链接器与先前编译遗留的 64 位和 32 位对象混淆？

于 2019-07-29T01:30:49.727 回答
-2

我已经为自己解决了这个问题，如下所示。

首先，我遵循了这个问题的其他答案，只是得出结论，所有项目设置都是正确的。

然后我用编辑器检查了 .vcxproj 文件，发现两个（Debug 和 Release）x64 配置的 <Link> 属性没有指定 <TargetMachine>，而 Win32 配置都包含 <TargetMachine> MachineX86</TargetMachine>。

但是，我已经从 Visual Studio 中的属性 > 配置属性 > 链接器 > 高级 > 目标机器中进行了验证，x64 配置表示 MachineX64 (/MACHINE:X64)。

因此，我编辑了 .vcxproj 文件以在两个 x64 配置中包含 <TargetMachine> MachineX64</TargetMachine>。回到 Visual Studio 项目属性对话框，我注意到 MachineX64 (/MACHINE:X64) 设置和以前一样，只是现在它以粗体显示（显然意味着该值不是默认值）。

我重建了，它奏效了。

于 2020-11-02T08:30:47.243 回答