Fatal error lnk1112 тип компьютера модуля x86 конфликтует с типом целевого компьютера x64

фатальная ошибка LNK1112: тип машины модуля ‘x64’ конфликтует с типом целевой машины ‘X86’

Я использую CUDA (VC ++, Visual studio 2008sp1) для отладки программы FEM. Программа может работать только на платформе Win32 из-за недостатка cuda. Я думаю, что все связанные файлы библиотеки скомпилированы на платформе x86, но когда я компилирую ее, я получаю сообщение об ошибке «фатальная ошибка LNK1112: тип машины модуля ‘x64’ конфликтует с типом целевой машины ‘X86’».

Я пытался конвертировать платформу в x64, но это не сработало. Скажите, пожалуйста, что такое «тип модульной машины» и что такое «тип целевой машины»? Как мне это преодолеть?

Я написал об этом запись в блоге, когда столкнулся с этой неприятной проблемой и, наконец, вернул свою систему в рабочее состояние.

Вот что нужно проверить в следующем порядке:

Проверьте параметры свойств в настройках компоновщика по адресу: Свойства> Свойства конфигурации> Компоновщик> Дополнительно> Целевой компьютер. Выберите MachineX64, если вы ориентируетесь на 64-битную сборку, или MachineX86, если вы делаете 32-битную сборку.

Выберите Сборка> Диспетчер конфигурации в главном меню Visual Studio. Убедитесь, что в вашем проекте указана правильная платформа. Для среды IDE можно настроить сборку x64, но для отдельного проекта в решении можно настроить целевой win32. Так что да, визуальная студия оставляет много веревок, чтобы повеситься, но это жизнь.

Убедитесь, что файлы вашей библиотеки действительно относятся к тому типу, на который нацелена платформа. Это можно использовать с помощью dumpbin.exe, который находится в каталоге Visual Studio VC bin. используйте параметр -headers, чтобы выгрузить все ваши функции. Найдите машинную запись для каждой функции. он должен включать x64, если это 64-битная сборка.

В Visual Studio выберите в главном меню Инструменты> Параметры. выберите Проекты и решения> Каталоги VC ++. В раскрывающемся списке «Платформа» выберите x64. Убедитесь, что первая запись: $ (VCInstallDir) bin x86_amd64 с последующим $ (VCInstallDir) bin.

Как только я сделал шаг 4, у меня снова все заработало. Дело в том, что я сталкивался с этой проблемой во всех своих проектах, где я хотел скомпилировать 64-битную цель.

• 6 Спасатель жизни. Также на шаге 4 «Каталоги библиотек» также необходимо обновить до 64-битных путей.
• 38 Для тех, кто использует Visual Studio 2013 — шаг 4 устарел, теперь вы вносите изменения в свойства проекта -> свойства конфигурации -> Каталоги VC ++ — Каталоги библиотек
• 3 Если вы используете внешнюю библиотеку, которая была скомпилирована как x86, вы также получите эту ошибку. Я столкнулся с этим при попытке создать проект с использованием библиотек Google Test.
• 3 Если у меня нет файла проекта (запущен nmake в Makefile), как мне сделать то же самое?
• 3 Как сделать это в командной строке вместо создания проекта в версии с графическим интерфейсом?

В добавление к C Джонсон list я бы добавил следующий пункт:

Проверьте в Visual Studio:
Свойства проекта -> Свойства конфигурации -> Компоновщик -> Командная строка.

«Дополнительные параметры» НЕ должны содержать /machine:X86

У меня есть такой ключ, сгенерированный выводом CMake: CMake сгенерировал проект x86, затем я добавил платформу x64 через Configuration Manager в Visual Studio 2010 — все было создано нормально для новой платформы, за исключением того, что в командной строке компоновщика указано /machine:X86 по отдельности.

• 21 Это и была моя проблема! Но это был сгенерированный CMake проект Visual Studio 2017, в котором я использовал Configuration Manager для создания конфигураций сборки платформы x64 (где конфигурации сборки Win32 были скопированы для создания конфигураций сборки x64). Что происходит, так это то, что настройки компоновщика «/ MACHINE:» между «Все параметры-> Дополнительные параметры» и «Дополнительно-> Целевая машина» конфликтуют. Чтобы исправить, просто удалите настройку «Все параметры-> Дополнительные параметры» -> «/ МАШИНА:».
• 2 Это, вероятно, сэкономило мне часы. Благодарность!
• 3 Это было исправление для меня, поэтому просто хотел сказать спасибо, как ни странно, я уже проголосовал за, так что я, должно быть, был здесь раньше с той же проблемой! 🙂
• 1 Небольшой вариант этого решения: некоторые проекты в моем решении не имеют «Linker» в свойствах конфигурации. Вместо них есть «Библиотекарь». В этих случаях действительно Librarian -> All Options -> Additional Options сказал / machine: x86, а Librarian -> All Options -> Target Machine сказал / machine: x64. Я удалил x86 из Библиотекаря -> Все параметры -> Дополнительные параметры . и все, наконец, построено и связано.
• Спасибо за эти советы. Кажется, это обычная проблема для пользователей CMake. Голосовать за.

У меня возникла та же проблема в VS2008, когда я попытался добавить сборку X64 в проект, преобразованный из VS2003.

Я просмотрел все, что нашел при поиске этой ошибки в Google (целевая машина, каталоги VC ++, DUMPBIN . ), и все выглядело нормально.

Наконец, я создал новый тестовый проект, внес те же изменения, и, похоже, он сработал.

Выполнение различия между файлами vcproj выявило проблему .

В моем преобразованном проекте / MACHINE: i386 была установлена ​​дополнительная опция в Linker-> Command Line. Таким образом, было установлено две опции / MACHINE (как x64, так и i386), и предпочтение было отдано дополнительной.

Удалив это и правильно настроив в Linker-> Advanced-> Target Machine, проблема исчезла.

• 8 Это была именно моя проблема — но она возникла из решения Visual Studio, созданного с помощью CMake. Похоже, CMake тоже любит добавлять эту опцию.
• 4 Я пришел из проекта CMake и могу подтвердить, что он добавил эту опцию.

Все настройки проекта казались идеальными, но ошибка все равно появлялась. Глядя в .vcxproj файл и поиск «x86» выявил проблему:

Быстрый поиск / замена для всех случаев (десять индивидуальных настроек файла) устранил проблему.

• 3 Также в «Свойства проекта» -> «Параметры конфигурации» -> «Библиотекарь» -> «Все параметры» -> «Дополнительные параметры».
• Это было проблемой в моем случае. Спасибо за этот ответ, он решил мою проблему.

Поскольку проблема связана с разницей в спецификациях компиляции и целевой машины (x86 и x64), выполните следующие действия:

1. Откройте проект C ++, который вы хотите настроить.
2. Нажмите кнопку Configuration Manager, чтобы открыть диалоговое окно Configuration Manager.
3. В раскрывающемся списке Active Solution Platform выберите параметр, чтобы открыть диалоговое окно New Solution Platform.
4. В раскрывающемся списке Тип или выберите новую платформу выберите 64-разрядную платформу.

Это решило мою проблему.

У вас, вероятно, есть один файл .OBJ или .LIB, предназначенный для x64 (это тип машины модуля), в то время как вы связываете для x86 (это тип целевой машины).

Используйте DUMPBIN / HEADERS для своих файлов .OBJ и проверьте запись машины в блоке FILE HEADER VALUES.

• 3 Это было для меня основной причиной, когда я столкнулся с этим сообщением об ошибке. Ранее я создавал для одной архитектуры и не очищал должным образом объектные файлы и библиотеки из предыдущей сборки. После удаления всех старых файлов .obj и .lib из предыдущей сборки я смог скомпилировать свой проект с новой архитектурой.
• Это была моя проблема, и решение было очистить перед сборкой при изменении целевой архитектуры.

В Visual Studio 2012 +/- страница свойств для «Свойства конфигурации». Линкер. «Командная строка» содержит поле с надписью «Дополнительные параметры». Если вы создаете x64, убедитесь, что это поле не содержит / MACHINE: I386. Мои проекты сделали, и это вызвало указанную ошибку.

Я столкнулся с этой проблемой при сборке QT. В инструкциях, которые я где-то читал, предлагалось настроить nmake с помощью командной строки VS.

Я выбрал командную строку x64 и без особых проблем выполнил настройку. Когда я попробовал nmake, он выдал эту ошибку.

Я думаю, что некоторые компоненты были предварительно созданы для 32-битной версии. Ошибка даже сообщала, какие модули были построены для x86.

Я использовал 32-битную командную строку VS по умолчанию, и она сработала.

• 4 Это поставило меня на верный путь. Если вы создаете для 64-битной версии, вы можете использовать этот ярлык Windows для настройки своей среды: C: Windows System32 cmd.exe / A / Q /KC:QtQt5.1.15.1.1msvc2012_64 bin qtenv2.bat & «C: Program Files (x86) Microsoft Visual Studio 11.0 VC vcvarsall.bat» x86_amd64 & cd c: YourDir Важной частью этого является x86_amd64 — без него среда устанавливается как 32-битная среда, и qmake подбирает ее как таковую.

Установите 64-битную опцию компиляции -m64 -cubin

Подсказка находится в журнале компиляции. Как это:

Что ‘-machine 32’ это проблема.

Сначала установите параметр компиляции 64bit, затем повторно установите параметр гибридной компиляции. Тогда вы увидите успех.

• — машина 32, два дефиса

В Visual Studio 2013

1) Проверьте страницы свойств проекта / Свойства конфигурации / Компоновщик / Все параметры и исправьте все пропущенные настроенные машины и каталоги.

2) Проверьте страницы свойств проекта / Свойства конфигурации / Компоновщик / Вход и исправьте все пропущенные настроенные каталоги.

Если в вашем решении есть проекты библиотеки, проверьте свойство Target Machine в Property-> Librarian-> General

Файл vcxproj может содержать MACHINE: i386. Отредактируйте файл vcxproj с помощью редактора. убери это !

В дополнение к списку Джонсона проверьте также папки библиотеки.

В Visual Studio выберите в главном меню Инструменты> Параметры. выберите Проекты и решения> Каталоги VC ++. В раскрывающемся списке «Платформа» выберите x64.

Это случилось со мной сегодня, потому что я добавил каталог библиотеки, еще находясь в режиме x86, и случайно удалил унаследованные каталоги, сделав их жестко запрограммированными. Затем после перехода на x64 мои каталоги VC ++ все еще читают:

• Спасибо. Это была моя проблема. Для будущих читателей мой «Каталоги библиотеки» теперь читает $(VC_LibraryPath_x64);$(WindowsSDK_LibraryPath_x64);$(NETFXKitsDir)Libumx64;

Я использовал CMake, а затем добавил конфигурацию win32. На странице собственности было показано x86 но на самом деле при открытии файла vcxproj в текстовом редакторе он был x64! Это решил ручной переход на x86.

• 2 У меня было нечто подобное. Я не знаю, где прятался параметр (и я последовал совету большинства ответов здесь), но указание генератора соответствующим образом помогло мне: cmake. -G «Visual Studio 12 Win 64».

Это очень расстраивающая и раздражающая проблема, но как только вы ее поймете, это довольно просто: у вас есть какой-то элемент, который вы строите, создавая один тип архитектуры (в вашем случае x64), несмотря на то, что он был предназначен для другого типа (скажем, x86 ).

Вы можете проанализировать источник вашей проблемы, посмотрев, какой obj-файл вызывает сбой, и начать искать проблему там. У каждого obj будет аналог исходного кода: либо в cpp, c, asm и т. Д.Вокруг него могут быть специальные события сборки, в которых используется неправильный инструмент. Проверьте это в листах свойств.

Я бы сначала посмотрел туда, прежде чем просматривать список дел, которые нужно сделать Си Джонсону.

Я решил эту проблему, изменив Win32 на * 64 в Visual Studio 2013.

Моя цель — приложение DOSBox в текстовом режиме x64 Windows 10 на языке C. Использование «Visual Studio 2019 Community» для компиляции через приглашение DOS «nmake -f makefile». Ошибка аналогична, но с противоположной стороны:

Можно скомпилировать с помощью VC ++ 2010 на другом компьютере. Но на этом компьютере произошла ошибка «Сообщества Visual Studio 2019». Итак, мои настройки верны, и все приведенные выше ответы не работают.

Я хотел бы поделиться с вами, что решение — это make.bat вроде этого:

Вы найдете много других vcvarsxxxx.bat, только это одно слово.

Тип машины модуля — это машина, на которой вы компилируете, а тип целевой машины — это архитектура x86 или x64, для которой вы создаете свои двоичные файлы.

Эта проблема также может возникнуть, если ваш проект настроен на использование тех же промежуточных каталогов в Project Properties -> Configuration Properties -> General

Прежде всего попробуйте следующее: 1. перейдите к диспетчеру конфигурации и создайте новый x64, если его еще нет. 2. выберите решение x64. 3. перейдите в свойства проекта и затем Linker-> Advanced выберите машину x64. 4. Теперь перестройте раствор.

Если все еще вы получаете ту же ошибку. попробуйте чистое решение, а затем перестройте его снова и откройте визуальную студию, вы получите список недавно открытых проектов, щелкните правой кнопкой мыши проект и удалите его оттуда. Теперь перейдите к раствору и снова откройте раствор.

это происходит со мной, когда я конвертирую свое решение VS2008 в VS2010 и меняю конфигурацию win32 на X64, в моем старом решении у меня есть mfcs90d.lib (Configuration-> Linker-> Input-> Additional dependencies), так как я использую VS010, который я только что проверил в папке VS2010, где это mfcs100d.lib, поэтому я изменил mfcs90d.lib на mfcs100d.lib в (Configuration-> Linker-> Input-> Additional dependencies), он работал нормально.

Для тех, кто использует QT Creator, проблема такая же (как описано @ c-johnson). Убедитесь, что настройки компилятора для MSVC в вашем комплекте установлены на x86, как показано ниже.

для некоторых, использующих командную строку (подсказка dos), это может быть полезно:

Также, если вам это нравится:

CL «% 1% 2% 3» / EHsc / link user32.lib Gdi32.lib Winmm.lib comctl32.lib * .obj / ПОДСИСТЕМА: КОНСОЛЬ / МАШИНА: x86

ты должен del * .obj перед; чтобы избежать путаницы компоновщика с 64- и 32-битными объектами, оставшимися от предыдущих компиляций?

Выше много хороших предложений.

Также, если вы пытаетесь собрать x86 Win32:

Убедитесь, что любые библиотеки, на которые вы ссылаетесь в Program Files (x86), на самом деле являются библиотеками x86, потому что они не обязательно .

Например, файл lib, с которым я связался в C: Program Files (x86) Microsoft Visual Studio 2019 Professional SDK, вызвал эту ошибку, в конце концов я нашел его версию x86 в C: Program Files (x86) Windows Kits 10 Lib 10.0.18362.0 um x86 и все работало нормально.

Я исправил для себя эту проблему следующим образом.

Прежде всего, я последовал другим ответам на этот вопрос только для того, чтобы сделать вывод, что все настройки проекта верны.

Затем я проверил файл .vcxproj с помощью редактора и заметил, что свойства для двух конфигураций (Debug и Release) x64 не указывали , в то время как конфигурации Win32 содержали MachineX86 .

Однако я уже убедился, глядя из Visual Studio в Свойства> Свойства конфигурации> Компоновщик> Дополнительно> Целевая машина, что в конфигурациях x64 указано MachineX64 (/ MACHINE: X64).

Итак, я отредактировал файл .vcxproj, чтобы включить MachineX64 в две конфигурации x64. Возвращаясь к диалоговому окну свойств проекта Visual Studio, я заметил, что параметр MachineX64 (/ MACHINE: X64) был там, как и раньше, за исключением того, что теперь он выделен жирным шрифтом (очевидно, это означает, что значение не является значением по умолчанию).

Я восстановил, и это сработало.

какая ОС? если это Windows x64, вам необходимо убедиться, что CUDA x64 был установлен и, таким образом, VS2008 должен скомпилировать проект в режиме x64 .

Как исправить ошибку 126?

Мы разработали серию решений проблемы, одно из них обязано помочь, так как исправляет каждую из перечисленных проблем. Логично, что после устранения неполадки, все должно заработать правильно.

Способ 1: автоматическое исправление проблем с DLL-файлами

Есть специальная утилита, которая автоматически сканирует системные библиотеки и сравнивает их с эталоном. Если она обнаружит, что какого-то файла или нескольких, недостает, она сама их загрузит. Также происходит анализ битых, поврежденных и модифицированных файлов. Это очень удобно и быстро в сравнении с ручным способом и, что немаловажно, еще и более безопасно. На личном опыте, программа работает стабильно и не устанавливает файлы, зараженные вирусами. Однако любые манипуляции с DLL-библиотеками сложно назвать полностью безопасными.

Инструкция по устранению ошибки 126:

1. Загружаем программу Restoro PC Repair Tool. Лучше это делать с официального сайта .
2. Устанавливаем и запускаем софт. Нажимаем на кнопку «Начать сканирование» (Start Scan).
3. После процедуры анализа системы кликаем по клавише «Восстановить все» (Repair All).

Важное достоинство программы – она оптимизирует компьютер, увеличивая его производительность (если в системе есть какие-то проблемы с DLL). Ее можно оставить в качестве настольного софта, так как утилита решает большой спектр проблем.

Способ 2: временно отключаем антивирус

Есть большая вероятность, что ошибка 126 спровоцирована антивирусной защитой системы. Если в момент установки программы антивирус посчитал один из компонентов угрозой и заблокировал его, он будет отсутствовать, а система писать «Не найден указанный модуль». В целом желательно отключать защиту в момент установки программ, которым доверяем.

1. Выключаем антивирус (встроенный Защитник Windows и/или сторонний).
2. Полностью удаляем программу через «Программы и компоненты» (пункт находится в Панели управления).
3. Начинаем установку утилиты снова, проверив, что сейчас антивирус не работает.
4. Проверяем результат.

Если сейчас программа заработала нормально, рекомендуем открыть антивирус и добавить в список его исключений данный софт. В противном случае со временем ошибка может вернуться, ведь антивирусная защита снова может заблокировать или удалить файл.

Важно! Для максимального результата лучше сделать полное удаление программы. Для этого можем воспользоваться iObit Uninstaller. Софт анализирует систему и ищет остатки файлов приложения, удаляя и их.

Способ 3: обновляем Microsoft NET Framework

Устаревание платформы Microsoft NET Framework нередко приводит к ошибкам с кодом 126 и 127. Благо, это просто решается, достаточно обновить среду. Если дело было в этом, все должно заработать. Скачать актуальную версию NET Framework можем с официального сайта Microsoft .

Способ 4: переустанавливаем DirectX

Очень много DLL-файлов напрямую связаны с DirectX, поэтому есть высокая вероятность, что сообщение «Не найден указанный модуль» относится к данному программному компоненту. Его легко переустановить, так как DirectX тоже распространяет Microsoft совершенно бесплатно и для любых версий, конфигураций операционной системы. С установкой проблем быть не должно, за исключением одного момента – желательно, перед началом инсталляции софта удалить старую версию DirectX.

Способ 5: сканируем системные файлы Windows

Во всех актуальных версиях Windows есть встроенный инструмент анализа системных файлов. Он часто помогает при различных проблемах с DLL-файлами.

Как запустить системные файлы:

1. В поиск Windows вводим cmd и запускаем «Командную строку».
2. Вводим команду sfc /scannow.
3. Ждем завершения сканирования системы. Все ошибки должны быть исправлены автоматически, если такая возможность есть.

Способ 6: восстанавливаем системные реестр

Ошибка 126 и 127 может быть следствием скопления мусора в реестре или повреждения значений в нем. Одна проблема – вручную все перелистать и исправить просто нереально. Для этого лучше использовать специальные программы, например, Total System Care . В утилите есть все необходимое для анализа системного реестра, его оптимизации и исправления существующих проблем. Еще можем порекомендовать CCleaner . Обе программы справятся со своими задачами.

Способ 7: делаем откат Windows

Если никакие ручные способы исправления не помогают, что бывает редко, приходится обратиться к последнему методу и откатить Windows к последнему рабочему состоянию. Иногда файлы DLL могут пропадать из-за удаления программы, и вы можете столкнуться с ошибкой 126. Чтобы устранить ее, воспользуйтесь точками восстановления. Найти «Параметры восстановления» можем через поиск в Windows.

Теперь ошибка с кодом 126 больше не должна беспокоить пользователя как в Windows 7, так и 8, 10. Одна из процедур практически 100% должна исправить проблему. При этом мы не рекомендуем вручную менять DLL-файл, если удалось обнаружить в каком именно проблема. Все из-за чрезмерно высокого шанса загрузить вирус.