我正在尝试在Visual Studio 2008中将原生ATL C ++进程内COM服务器移植到64位。我打开了配置管理器，添加了“x64”平台。现在我有6个配置 - 3个用于Win32，编译和链接正常，3个用于x64编译正常，但使链接器发出以下错误：
\Debug64\Objects\common.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
我该怎么做才能让它消失？
UPD：已经解决了，问题来源令人惊讶地愚蠢，请参阅下面的答案。答案 0 :(得分：2)
您是否在Visual Studio安装期间安装了“x64 compiler and tools”组件？
同时检查以下设置：（copied from msdn）
/ MACHINE（指定目标平台）设置为/ MACHINE：IA64或/ MACHINE：X64。
注册输出已关闭。有关更多信息，请参阅链接器属性页。
目标环境设置为/ env x64或/ env ia64。有关更多信息，请参阅MIDL属性页：常规。
清除验证参数并将其重置为默认值。有关更多信息，请参阅MIDL属性页：高级。
如果在Win32项目配置中将调试信息格式设置为/ ZI，则在64位项目配置中将其设置为/ Zi。有关更多信息，请参见/ Z7，/ Zi，/ ZI（调试信息格式）。
WIN32的值替换为WIN64 for / D（预处理器定义）。
答案 1 :(得分：0)
你确定 common.obj的目标机器是x86吗？因为链接器告诉你它不是。 检查解决方案 - ＆gt;属性 - ＆gt;配置平台确实是x64，并将其设置在project-＆gt; properties-＆gt; linker-＆gt; advanced-＆gt;目标机器中。并重建。
答案 2 :(得分：0)
常见问题是无法使用Debug64和Release64目录。确切名称并不重要，但如果最终在单个目录中混合使用32位和64位.objs，.libs或.dll，则链接器将出现问题。
通过执行干净构建，确定这是否有所贡献的快速方法。如果链接问题没有消失，那么混合中间二进制文件不是原因
答案 3 :(得分：0)
嗯，真正的原因非常简单。我们不使用VS附带的.cmd文件来设置环境变量，而是使用我们自己的等效.cmd文件。该文件为32位cl.exe设置％PATH％变量，这正是C ++源代码使用32位编译器编译的原因。解决方案是使用VS附带的.64d进行x64编译，或者适当地设置自定义.cmd文件设置％PATH％。