I’m using CUDA (VC++, Visual studio 2008sp1) to debug a FEM program. The program can only run on a Win32 platform, for the insufficiency of cuda. I think the library files linked are all compiled on the x86 platform, but when I compile it, I get the error message
fatal error LNK1112: module machine type ‘x64’ conflicts with target machine type ‘X86’.
I have tried to convert the platform to x64, but it didn’t work. Please tell me: what is «module machine type» and what is «target machine type»? How can I overcome it?
Jarod42
198k13 gold badges178 silver badges288 bronze badges
asked Aug 25, 2010 at 7:36
I wrote a blog entry about this, as I encountered this maddening problem, and finally yanked my system back into working order.
These are the things to check, in this order:
-
Check your properties options in your linker settings at: Properties > Configuration Properties > Linker > Advanced > Target Machine. Select MachineX64 if you are targeting a 64 bit build, or MachineX86 if you are making a 32 bit build.
-
Select Build > Configuration Manager from the main menu in visual studio. Make sure your project has the correct platform specified. It is possible for the IDE to be set to build x64 but an individual project in the solution can be set to target win32. So yeah, visual studio leaves a lot of rope to hang yourself, but that’s life.
-
Check your library files that they really are of the type of platform are targeting. This can be used by using dumpbin.exe which is in your visual studio VCbin directory. use the -headers option to dump all your functions. Look for the machine entry for each function. it should include x64 if it’s a 64 bit build.
-
In visual studio, select Tools > Options from the main menu. select Projects and Solutions > VC++ Directories. Select x64 from the Platform dropdown. Make sure that the first entry is: $(VCInstallDir)binx86_amd64 followed by $(VCInstallDir)bin.
Once I did step 4 everything worked again for me. The thing was I was encountering this problem on all my projects where I wanted to compile towards a 64 bit target.
Sep
3373 silver badges12 bronze badges
answered Dec 6, 2010 at 7:06
C.J.C.J.
15.5k9 gold badges60 silver badges77 bronze badges
13
In addition to C Johnson list I would add the following point:
Check in Visual Studio:
Project Properties -> Configuration Properties -> Linker -> Command line.
«Additional Options» should NOT contain /machine:X86
I have such key, generated by CMake output: CMake generated x86 project, then I added x64 platform via Configuration Manager in Visual Studio 2010 — everything was created fine for the new platform except that the linker command line, specified /machine:X86 separately.
Heyji
1,0838 silver badges26 bronze badges
answered Apr 8, 2013 at 22:35
sergtksergtk
10.5k15 gold badges75 silver badges129 bronze badges
6
I experienced the same problem in VS2008 when I tried to add a X64 build to a project converted from VS2003.
I looked at everything found when searching for this error on Google (Target machine, VC++Directories, DUMPBIN….) and everything looked OK.
Finally I created a new test project and did the same changes and it seemed to work.
Doing a diff between the vcproj files revealed the problem….
My converted project had /MACHINE:i386 set as additional option set under Linker->Command Line. Thus there was two /MACHINE options set (both x64 and i386) and the additional one took preference.
Removing this and setting it properly under Linker->Advanced->Target Machine made the problem disappeared.
CassOnMars
6,1432 gold badges33 silver badges46 bronze badges
answered Jan 13, 2012 at 8:28
ZidZid
5614 silver badges2 bronze badges
2
All project settings seemed perfect, but I still got the error. Looking into the .vcxproj file and searching for «x86» revealed the problem:
<Lib>
<AdditionalOptions> /machine:X86 %(AdditionalOptions)</AdditionalOptions>
</Lib>
A quick search/replace for all occurrances (ten individual file settings) fixed the problem.
answered Mar 13, 2017 at 20:20
kungfoomankungfooman
4,2271 gold badge42 silver badges30 bronze badges
2
You probably have one .OBJ or .LIB file that’s targeted for x64 (that’s the module machine type) while you’re linking for x86 (that’s the target machine type).
Use DUMPBIN /HEADERS on your .OBJ files and check for the machine entry in the FILE HEADER VALUES block.
answered Aug 25, 2010 at 8:01
PatrickPatrick
23k11 gold badges66 silver badges129 bronze badges
2
Since the problem is due to the difference in compilation and target machine specifications (x86 & x64)
Follow the steps below:
- Open the C++ project that you want to configure.
- Choose the Configuration Manager button to open the Configuration Manager dialog box.
- In the Active Solution Platform drop-down list, select the option to open the New Solution Platform dialog box.
- In the Type or select the new platform drop-down list, select a 64-bit platform.
It solved my problem.
answered May 13, 2014 at 20:55
habhab
6172 gold badges8 silver badges20 bronze badges
In Visual Studio 2012 +/-, the property page for «Configuration Properties’.Linker.»Command Line» contains a box labeled «Additional Options». If you’re building x64, make sure that box doesn’t contain /MACHINE:I386. My projects did and it generated the error in question.
answered Nov 15, 2014 at 4:59
laloumenlaloumen
1,1891 gold badge13 silver badges15 bronze badges
0
I came across this problem when building QT. The instructions I read somewhere suggested that I configure nmake using VS command prompt.
I chose the x64 command prompt and performed configure without much hassle. When i tried nmake, it gave this error.
I think some of the components were pre-built for 32-bit. The error even reported which modules were built for x86.
I used the 32 bit default VS command prompt and it worked.
Trevor Hickey
35.5k28 gold badges153 silver badges263 bronze badges
answered Aug 29, 2013 at 9:52
1
"project property - CUDA Runtime API - GPU - NVCC Compilation Type"
Set the 64 bit compile option -m64 -cubin
The hint is at compile log.
Like this:
nvcc.exe ~~~~~~ -machine 32 -ccbin ~~~~~
That "-machine 32" is problem.
First set 64bit compile option,
next re setting hybrid compile option.
Then u can see the succeed.
Zaheer Ahmed
28k11 gold badges73 silver badges110 bronze badges
answered Jul 25, 2013 at 10:34
changchang
311 bronze badge
1
In Visual Studio 2013,
1) Check in the Project Property Pages / Configuration Properties / Linker / All Options and correct all the miss configured machine and directories.
2) Check in the Project Property Pages / Configuration Properties / Linker / Input and correct all the miss configured directories.
See example of 1)
shriek
5,1472 gold badges35 silver badges42 bronze badges
answered Jan 3, 2014 at 17:43
If your solution has lib projects check Target Machine property in Property->Librarian->General
answered Oct 28, 2013 at 9:47
RinatRinat
212 bronze badges
0
vcxproj file may contain ‘MACHINE:i386’
Edit vcxproj file with editor. remove it !
answered Sep 29, 2017 at 2:00
Mark YangMark Yang
2203 silver badges16 bronze badges
My target is a x64 Windows 10 text mode DOSBox application in C language.
Using «Visual Studio 2019 Community» to compile through DOS prompt «nmake -f makefile».
The error is similar but on the opposite side:
fatal error LNK1112: module machine type 'x32' conflicts with target machine type 'X64'
It’s ok to compile by VC++ 2010 on another computer. But failed on this computer by «Visual Studio 2019 Community». So my settings are correct and all above answers do not work.
I’d like to share you that the solution is a make.bat like this:
call "c:Program Files (x86)Microsoft Visual Studio2019CommunityVCAuxiliaryBuildvcvars64.bat"
nmake -f makefile
You will find there are many other vcvarsxxxx.bat, only this one words.
answered Oct 10, 2020 at 0:01
H.C.ChenH.C.Chen
4124 silver badges14 bronze badges
In addition to Jhonson’s list, also check library’s folders
In visual studio, select Tools > Options from the main menu. select Projects and Solutions > VC++ Directories. Select x64 from the Platform dropdown.
$(VCInstallDir)libAMD64;
$(VCInstallDir)atlmfclibamd64;
$(WindowsSdkDir)libx64;
answered Jan 13, 2014 at 15:55
0
This happened to me today because I had added a library directory while still in x86 mode, and accidently removed the inherited directories, making them hardcoded instead.
Then after switching to x64, my VC++ Directories still read:
«…;$(VC_LibraryPath_x86);$(WindowsSDK_LibraryPath_x86);»
instead of the _x64.
answered Oct 17, 2015 at 18:41
masterxilomasterxilo
2,3741 gold badge29 silver badges34 bronze badges
1
I was using CMake & then added a win32 configuration. The property page showed x86 but actually when opening the vcxproj file in a text editor it was x64! Manually changing to x86 solved this.
answered Jan 31, 2016 at 17:44
gruntgrunt
6521 gold badge7 silver badges24 bronze badges
1
First of all try the following things:
1. goto configuration Manager and create a new x64 if it is not already there.
2. select the x64 solution.
3. go to project properties and then Linker->Advanced select x64 machine.
4. Now rebuild the solution.
If still you are getting the same error. try clean solution and then rebuild again and open visual studio you will get list of recent opened project , right click on the project and remove it from there. Now go to the solution and reopen the solution again.
answered Jun 2, 2016 at 11:05
It’s a very frustrating and annoying problem but once you understand it, it’s quite simple: you have some element in you’re build that building one architecture type (in your case x64) despite the fact that it’s been target for another type (say x86).
You can dissect the source of your problem by looking at which obj file is causing the crash and start looking for the problem there. Every obj will have a source code analog: either in cpp, c, asm etc. There may be special build events around it that are using the wrong tool. Check for that in the property sheets.
I’d look there first before going through C Johnson list of things to do.
answered Jan 28, 2017 at 21:34
I solved this problem by changing Win32 to *64 in Visual Studio 2013.
answered Aug 8, 2018 at 9:44
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 Studio2019ProfessionalSDK threw that error, eventually I found an x86 version of it in C:Program Files (x86)Windows Kits10Lib10.0.18362.0umx86 and everything worked fine.
answered Jan 9, 2020 at 15:28
GrahamJGrahamJ
5184 silver badges15 bronze badges
Properties->configurationManager-> ActiveSolutionPlatform . Here select x64 .thats all.
It should take care of all dependencies and compilation should work smoothly
answered Jan 19, 2022 at 6:28
user265906user265906
1001 silver badge8 bronze badges
module machine type is the machine on which you are compiling and the target machine type is the the architecture x86 or x64 for which you are building your binaries.
answered Oct 16, 2013 at 4:40
This problem may also happen if your project set up to have the same intermediate directories in Project Properties -> Configuration Properties -> General
answered Jun 6, 2015 at 17:03
Anton KAnton K
4,5822 gold badges48 silver badges59 bronze badges
this happens to me when i convert my VS2008 solution to VS2010 & change win32 configuration to X64, in my old solution I have mfcs90d.lib (Configuration->Linker->Input->Additional dependencies), as I am using VS010 i just checked in VS2010 folder where it is mfcs100d.lib, so I changed mfcs90d.lib to mfcs100d.lib in (Configuration->Linker->Input->Additional dependencies) it worked fine.
answered Mar 2, 2017 at 9:03
NDestinyNDestiny
1,1031 gold badge11 silver badges28 bronze badges
For those who are with QT Creator, the issue is same (as described by @c-johnson).
Make sure the compiler settings for MSVC in your kit is set to x86 as shown below.
answered Jul 9, 2019 at 15:41
Jimson JamesJimson James
2,5926 gold badges39 silver badges69 bronze badges
for some using command prompt (dos prompt)
this might be helpful:
call "C:Program Files (x86)Microsoft Visual Studio 14.0VCvcvarsall.bat" --help
Error in script usage. The correct usage is:
"C:Program Files (x86)Microsoft Visual Studio 14.0VCvcvarsall.bat" [option]
or
"C:Program Files (x86)Microsoft Visual Studio 14.0VCvcvarsall.bat" [option] store
or
"C:Program Files (x86)Microsoft Visual Studio 14.0VCvcvarsall.bat" [option] [version number]
or
"C:Program Files (x86)Microsoft Visual Studio 14.0VCvcvarsall.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.0VCvcvarsall.bat" x86_amd64
"C:Program Files (x86)Microsoft Visual Studio 14.0VCvcvarsall.bat" x86_arm store
"C:Program Files (x86)Microsoft Visual Studio 14.0VCvcvarsall.bat" x86_amd64 10.0.10240.0
"C:Program Files (x86)Microsoft Visual Studio 14.0VCvcvarsall.bat" x86_arm store 10.0.10240.0
"C:Program Files (x86)Microsoft Visual Studio 14.0VCvcvarsall.bat" x64 8.1
"C:Program Files (x86)Microsoft Visual Studio 14.0VCvcvarsall.bat" x64 store 8.1
:
Please make sure either Visual Studio or C++ Build SKU is installed.
Also If you do like this:
CL «%1%2%3» /EHsc /link user32.lib Gdi32.lib Winmm.lib comctl32.lib *.obj /SUBSYSTEM:CONSOLE /MACHINE:x86
you have to del *.obj before; to avoid confusing linker with both 64 and 32 bit objects left over from prior compilations?
answered Jul 29, 2019 at 1:30
kris2kkris2k
3053 silver badges5 bronze badges
I have fixed this problem for myself as follows.
First of all, I followed the other answers for this question, only to conclude that all the project settings were correct.
Then I inspected the .vcxproj file with an editor and noticed that the < Link > properties for the two (Debug and Release) x64 configurations did not specify < TargetMachine >, while the Win32 configurations both contained < TargetMachine > MachineX86 < /TargetMachine >.
However, I had already verified, looking from Visual Studio at Properties > Configuration Properties > Linker > Advanced > Target Machine, that the x64 configurations said MachineX64 (/MACHINE:X64).
So, I edited the .vcxproj file to include < TargetMachine > MachineX64 < /TargetMachine > in the two x64 configs. Going back to the Visual Studio project properties dialog, I noticed that the MachineX64 (/MACHINE:X64) setting was there as before, except that now it showed in bold (apparently meaning that the value is not the default one).
I rebuilt, and it worked.
answered Nov 2, 2020 at 8:30
|
0 / 0 / 0 Регистрация: 22.12.2016 Сообщений: 69 |
|
|
1 |
|
|
11.09.2017, 16:15. Показов 21303. Ответов 12
Ошибка 17 error LNK1112: тип компьютера модуля «X86» противоречит типу целевого компьютера «x64» C:UsersHPDocumentsVisual Studio 2013ProjectsANNOSUANNOSUmsvcprt.lib(MSVCP120.d ll) ANNOSU
__________________
0 |
|
Programming Эксперт 94731 / 64177 / 26122 Регистрация: 12.04.2006 Сообщений: 116,782 |
11.09.2017, 16:15 |
|
Ответы с готовыми решениями:
Ввести структуру «историческое событие» с полями «число», «месяц», «год», «событие» Подсчитать общее количество вхождений в строку символов «А», «a», «B» и «b» main() int i; Динамическая память. Ошибка С2143 пишет отсутствие «;» перед «тип» (Visual Studio 2010) Чтение данных для выч. модуля программы из файла (вектора X, чисел N, M; inNm… 12 |
|
Модератор 11659 / 7172 / 1704 Регистрация: 25.07.2009 Сообщений: 13,142 |
|
|
11.09.2017, 16:30 |
2 |
|
Уже несколько часов пытаюсь исправить, ничего найти не могу. А не нужно на 32-битной ОС пытаться под 64 битную програмки компилить…
0 |
|
0 / 0 / 0 Регистрация: 22.12.2016 Сообщений: 69 |
|
|
11.09.2017, 16:34 [ТС] |
3 |
|
easybudda, да вроде не 32
0 |
|
0 / 0 / 0 Регистрация: 22.12.2016 Сообщений: 69 |
|
|
11.09.2017, 16:35 [ТС] |
4 |
|
вот Миниатюры
0 |
|
Модератор 11659 / 7172 / 1704 Регистрация: 25.07.2009 Сообщений: 13,142 |
|
|
11.09.2017, 16:44 |
5 |
|
0 |
|
0 / 0 / 0 Регистрация: 22.12.2016 Сообщений: 69 |
|
|
11.09.2017, 17:17 [ТС] |
6 |
|
easybudda, я наверное главного не сказал, но другие проекты компилируются под 64 и дело скорей всего в настройках проекта и коде
0 |
|
0 / 0 / 0 Регистрация: 22.12.2016 Сообщений: 69 |
|
|
11.09.2017, 20:29 [ТС] |
7 |
|
Создал новый проект , туда код скопировал прописал путь , теперь компилируется. Но появилась новая ошибка на др. компе где не студии выдает ошибку, отсутствует MSVCR120.dll, если скинуть туда файлы msvcr120.dll и msvcp120.dll, появляется другая . Компилирую под х64 release. Изображения
0 |
|
Модератор 7502 / 4370 / 2776 Регистрация: 22.11.2013 Сообщений: 12,506 Записей в блоге: 1 |
|
|
11.09.2017, 21:55 |
8 |
|
Поставьте на целевой машине рантайм от вашей студии, vcredist_*.exe сообразно платформе, или оба.
0 |
|
0 / 0 / 0 Регистрация: 22.12.2016 Сообщений: 69 |
|
|
12.09.2017, 05:42 [ТС] |
9 |
|
bormant, та ошибка появилась после установки vcredist x64/86 2013.
0 |
|
Модератор 7502 / 4370 / 2776 Регистрация: 22.11.2013 Сообщений: 12,506 Записей в блоге: 1 |
|
|
12.09.2017, 07:37 |
10 |
|
0xC000007b — это invalid image format.
0 |
|
0 / 0 / 0 Регистрация: 22.12.2016 Сообщений: 69 |
|
|
12.09.2017, 08:28 [ТС] |
11 |
|
bormant, в определении препроцессора написано WIN32, так и должно быть?
0 |
|
Модератор 7502 / 4370 / 2776 Регистрация: 22.11.2013 Сообщений: 12,506 Записей в блоге: 1 |
|
|
12.09.2017, 09:41 |
12 |
|
Решение
С какой еще разрядностью я мог напутать? .exe и загружаемые им .dll должны иметь одинаковую разрядность. Либо всё 32 бита, либо всё 64. Иначе будет ошибка 0xc000007b.
3 |
|
0 / 0 / 0 Регистрация: 22.12.2016 Сообщений: 69 |
|
|
12.09.2017, 13:35 [ТС] |
13 |
|
bormant, спасибо за помощь , как оказалось у меня библиотека fftw 32 лежала в папке винды и прога соответственно брала библиотеку не из своей директории а из system32.
0 |
Содержание
- Ошибка средств компоновщика LNK1112
- Комментарии
- Фатальная ошибка LNK1112: тип модуля модуля «x64» конфликтует с типом целевой машины «X86»
- проблема связывания: фатальная ошибка LNK1112: тип компьютера модуля ‘x64’ конфликтует с типом машины назначения ‘X86’
- 12 ответов
- проблема связывания: фатальная ошибка LNK1112: тип компьютера модуля ‘x64’ конфликтует с типом машины назначения ‘X86’
- 12 ответов
- Fatal error lnk1112 тип компьютера модуля x86 конфликтует с типом целевого компьютера x64
- фатальная ошибка LNK1112: тип машины модуля ‘x64’ конфликтует с типом целевой машины ‘X86’
- Как исправить ошибку 126?
- Способ 1: автоматическое исправление проблем с DLL-файлами
- Способ 2: временно отключаем антивирус
- Способ 3: обновляем Microsoft NET Framework
- Способ 4: переустанавливаем DirectX
- Способ 5: сканируем системные файлы Windows
- Способ 6: восстанавливаем системные реестр
- Способ 7: делаем откат Windows
Ошибка средств компоновщика LNK1112
Тип компьютера модуля «type1» конфликтует с типом целевого компьютера «тип2«
Комментарии
Файлы объектов, указанные в качестве входных данных, были скомпилированы для другой целевой платформы.
Например, если попытаться связать файл объекта, скомпилированный с /clr файлом объекта и скомпилированным с /clr:pure помощью (ceE типа компьютера), компоновщик создаст ошибку LNK1112. Параметр /clr:pure компилятора не рекомендуется использовать в Visual Studio 2015 г. и не поддерживается в Visual Studio 2017 г.
Аналогичным образом, если создать один модуль с компилятором x64 и другим модулем с компилятором x86 и попытаться связать их, компоновщик создаст LNK1112.
Возможная причина этой ошибки заключается в том, что вы разрабатываете 64-разрядное приложение, но не установили один из 64-разрядных компиляторов Visual C++. Кроме того, вы используете платформу ARM или ARM64, но у вас нет установленных средств сборки ARM или ARM64. Чтобы устранить эту проблему, запустите Visual Studio Installer и установите отсутствующие компоненты C++.
Эта ошибка также может возникать при изменении активной конфигурации решения в диспетчере конфигураций и последующей попытке построения проекта до удаления промежуточных файлов проекта. Чтобы устранить эту ошибку, выберите в меню Сборка пункт Перестроить решение . Можно также выбрать в меню Сборка пункт Очистить решение , а затем выполнить сборку решения.
Источник
Фатальная ошибка LNK1112: тип модуля модуля «x64» конфликтует с типом целевой машины «X86»
Я использую CUDA (VС++, Visual studio 2008sp1) для отладки программы FEM. Программа может работать только на платформе Win32, для недостаточности cuda. Я думаю, что связанные с библиотекой файлы скомпилированы на платформе x86, но когда я ее компилирую, я получаю сообщение об ошибке “Неустранимая ошибка LNK1112: тип машинного модуля” x64 “конфликтует с типом целевой машины” X86 “.
Я попытался преобразовать платформу в x64, но это не сработало. Скажите, пожалуйста, что такое “тип модульной машины” и что такое “тип целевой машины”? Как я могу его преодолеть?
Я написал запись в блоге об этом, когда столкнулся с этой сводящей с ума проблемой, и наконец вернул мою систему в рабочее состояние.
Вот что нужно проверить в следующем порядке:
Проверьте параметры свойств в настройках компоновщика по адресу: Свойства> Свойства конфигурации> Компоновщик> Дополнительно> Целевой компьютер. Выберите MachineX64, если вы используете 64-битную сборку, или MachineX86, если вы делаете 32-битную сборку.
Выберите Build> Configuration Manager из главного меню в Visual Studio. Убедитесь, что в вашем проекте указана правильная платформа. Возможно, для среды IDE будет установлена сборка x64, но для отдельного проекта в решении может быть задано целевое значение win32. Так что да, визуальная студия оставляет много веревки, чтобы повеситься, но эта жизнь.
Проверьте файлы своей библиотеки, что они действительно относятся к тому типу платформы, на который нацелены. Это можно использовать с помощью dumpbin.exe, который находится в каталоге Visual Studio VCbin. используйте опцию -headers для сброса всех ваших функций. Ищите запись машины для каждой функции. он должен включать x64, если это 64-битная сборка.
В Visual Studio выберите Инструменты> Параметры в главном меню. выберите Проекты и решения> VC++ Каталоги. Выберите x64 из раскрывающегося списка Платформа. Убедитесь, что первая запись: $ (VCInstallDir)binx86_amd64, за которой следует $ (VCInstallDir)bin.
Как только я сделал шаг 4, все снова заработало для меня. Дело в том, что я сталкивался с этой проблемой во всех моих проектах, где я хотел скомпилировать в направлении 64-битной цели.
В дополнение к списку С. Джонсона я бы добавил следующее:
Проверьте в Visual Studio:
Свойства проекта → Свойства конфигурации → Компоновщик → Командная строка.
“Дополнительные параметры” НЕ должны содержать /machine:X86
У меня есть такой ключ, сгенерированный выводом CMake: CMake сгенерировал проект x86, затем я добавил платформу x64 через Configuration Manager в Visual Studio 2010 – все было прекрасно создано для новой платформы, за исключением командной строки компоновщика, указано /machine:X86 отдельно.
У меня возникла такая же проблема в VS2008, когда я попытался добавить сборку X64 в проект, преобразованный из VS2003.
Я просмотрел все, что было обнаружено при поиске этой ошибки в Google (целевой компьютер, каталоги VС++, DUMPBIN….), и все выглядело нормально.
Наконец, я создал новый тестовый проект и сделал те же изменения, и он, похоже, сработал.
Выполнение разницы между файлами vcproj показало проблему….
Мой преобразованный проект имел /MACHINE: i386 установлен как дополнительная опция, установленная в Linker- > Command Line. Таким образом, были установлены два параметра /MACHINE (как x64, так и i386), а дополнительный – предпочтение.
Удаление и правильная настройка в Linker- > Advanced- > Target Machine устранили проблему.
Все настройки проекта казались идеальными, но я все еще получил ошибку. В файле .vcxproj и поиске “x86” была обнаружена проблема:
Быстрый поиск/замена для всех событий (десять отдельных параметров файла) устранил проблему.
Поскольку проблема связана с различием в спецификации компиляции и целевой машины (x86 и x64)
Выполните следующие шаги:
- Откройте проект С++, который вы хотите настроить.
- Выберите кнопку Configuration Manager, чтобы открыть диалоговое окно Configuration Manager.
- В раскрывающемся списке “Платформа Active Solution” выберите параметр, чтобы открыть диалоговое окно “Новая платформа решений”.
- В раскрывающемся списке Тип или выберите новую платформу выберите 64-битную платформу.
Он решил мою проблему.
У вас, вероятно, есть один файл .OBJ или .LIB, предназначенный для x64 (тип модуля модуля), когда вы привязываетесь к x86 (тип целевой машины).
Используйте DUMPBIN/HEADERS в ваших .OBJ файлах и проверьте наличие записи в блоке FILE HEADER VALUES.
В Visual Studio 2012 +/- на странице свойств “Свойства конфигурации”.Linker. “Командная строка” содержит поле с надписью “Дополнительные параметры”. Если вы создаете x64, убедитесь, что в поле не содержится /MACHINE: I386. Мои проекты выполнялись, и это породило ошибку, о которой идет речь.
Я столкнулся с этой проблемой при построении QT. В инструкциях, которые я читал, я предложил настроить nmake с помощью командной строки VS.
Я выбрал командную строку x64 и выполнил настройку без особых проблем. Когда я попробовал nmake, он дал эту ошибку.
Я думаю, что некоторые из компонентов были предварительно построены для 32-битных. Ошибка даже сообщила, какие модули были построены для x86.
Я использовал 32-битную командную строку по умолчанию VS, и она сработала.
В Visual Studio 2013,
1) Проверьте страницы свойств проекта/свойства конфигурации/компоновщик/все параметры и исправьте все пропущенные машины и каталоги.
2) Проверьте страницы свойств проекта/свойства конфигурации/компоновщик/ввод и исправьте все пропущенные настроенные каталоги.
См. пример 1)
Задайте опцию компиляции 64 бит -m64 -cubin
Подсказка в журнале компиляции.
Вот так:
Это «-machine 32» является проблемой.
Первый набор 64-битной опции компиляции,
следующий параметр настройки гибридной компиляции.
Тогда u может видеть успешное выполнение.
Если ваше решение имеет проекты lib, проверьте свойство Target Machine в Property- > Librarian- > General
В дополнение к списку Jhonson также проверяйте папки библиотек
В визуальной студии выберите “Инструменты” > “Параметры” в главном меню. выберите “Проекты и решения” > “Каталоги VС++”. Выберите x64 в раскрывающемся списке “Платформа”.
Это случилось со мной сегодня, потому что я добавил каталог библиотеки в режиме x86 и случайно удалил унаследованные каталоги, сделав их жестко закодированными.
Затем, перейдя на x64, мои VС++-каталоги все еще читают:
Я использовал CMake, а затем добавил конфигурацию win32. На странице свойств было показано x86, но при открытии файла vcxproj в текстовом редакторе было x64! Ручное изменение на x86 решило это.
Это очень неприятная и неприятная проблема, но как только вы ее понимаете, это довольно просто: у вас есть какой-то элемент в вашей сборке, который создает один тип архитектуры (в вашем случае x64), несмотря на то, что он был целью для другого типа (скажем, x86).
Вы можете проанализировать источник своей проблемы, посмотрев, какой файл obj вызывает сбои и начинает искать проблему. Каждый obj будет иметь аналог исходного кода: либо в cpp, c, asm и т.д. Вокруг него могут быть специальные события сборки, которые используют неправильный инструмент. Проверьте это в листах свойств.
Я бы посмотрел там сначала, прежде чем переходить к списку дел Джонсона.
Файл vcxproj может содержать “MACHINE: i386”
Отредактируйте файл vcxproj с помощью редактора. удалите его!

Тип модуля модуля – это машина, на которой вы компилируете, а тип целевой машины – это архитектура x86 или x64, для которой вы создаете свои двоичные файлы.
Эта проблема также может возникнуть, если ваш проект настроен на наличие одинаковых промежуточных каталогов в свойствах проекта → Свойства конфигурации → Общие
Прежде всего, попробуйте следующее:
1. goto Configuration Manager и создайте новый 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 prompt)
это может быть полезно:
Кроме того, если вам это нравится:
CL “% 1% 2% 3″/EHsc/link user32.lib Gdi32.lib Winmm.lib comctl32.lib *.obj/SUBSYSTEM: CONSOLE/MACHINE: x86
Вы должны del *.obj до; чтобы не путать компоновщик с 64- и 32-битными объектами, оставшимися от предыдущих компиляций?
что такое ОС? если это окно x64, то вам нужно убедиться, что CUDA x64 установлен и, следовательно, VS2008 должен скомпилировать проект в режиме x64…
Источник
проблема связывания: фатальная ошибка LNK1112: тип компьютера модуля ‘x64’ конфликтует с типом машины назначения ‘X86’
Я пытаюсь запустить пример приложения из библиотеки wxFreeChart. После компиляции при связывании возникает ошибка:
Я попытался переключить опцию компоновщика advancedtarget на MachineX64, но он не работает.
Im с помощью visual studio 2008, любое предложение?
спасибо за помощь
12 ответов
Ошибка явная, вы пытаетесь связать библиотеки, которые были скомпилированы с разными целями ЦП. Исполняемое изображение может содержать только чистый x86 (32-разрядный) или чистый x64 (64-разрядный) код. Смешивание невозможно.
Вы изменяете целевой ЦП, создавая новую конфигурацию для проекта, но изменить настройку компоновщика недостаточно. Build + Configuration Manager, активная платформа платформы решений в правом верхнем углу, выберите «Создать» и выберите «x64». Это создает новую конфигурацию с несколькими измененными настройками проекта, что наиболее важно для компилятора, который будет использоваться.
Остерегайтесь того, что до VS2010 64-разрядные компиляторы по умолчанию не установлены. Если вы не видите x64 в комбо-платформе, вам необходимо повторно запустить setup.exe и включить параметр для установки 64-разрядных компиляторов. Затем снова запустите любой установщик пакета обновления, который вы, возможно, применили.
Возможный подход с меньшими болевыми точками — использовать 32-битную версию библиотеки.
Источник
проблема связывания: фатальная ошибка LNK1112: тип компьютера модуля ‘x64’ конфликтует с типом машины назначения ‘X86’
Я пытаюсь запустить пример приложения из библиотеки wxFreeChart. После компиляции при связывании возникает ошибка:
Я попытался переключить опцию компоновщика advancedtarget на MachineX64, но он не работает.
Im с помощью visual studio 2008, любое предложение?
спасибо за помощь
12 ответов
Ошибка явная, вы пытаетесь связать библиотеки, которые были скомпилированы с разными целями ЦП. Исполняемое изображение может содержать только чистый x86 (32-разрядный) или чистый x64 (64-разрядный) код. Смешивание невозможно.
Вы изменяете целевой ЦП, создавая новую конфигурацию для проекта, но изменить настройку компоновщика недостаточно. Build + Configuration Manager, активная платформа платформы решений в правом верхнем углу, выберите «Создать» и выберите «x64». Это создает новую конфигурацию с несколькими измененными настройками проекта, что наиболее важно для компилятора, который будет использоваться.
Остерегайтесь того, что до VS2010 64-разрядные компиляторы по умолчанию не установлены. Если вы не видите x64 в комбо-платформе, вам необходимо повторно запустить setup.exe и включить параметр для установки 64-разрядных компиляторов. Затем снова запустите любой установщик пакета обновления, который вы, возможно, применили.
Возможный подход с меньшими болевыми точками — использовать 32-битную версию библиотеки.
Источник
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), выполните следующие действия:
- Откройте проект C ++, который вы хотите настроить.
- Нажмите кнопку Configuration Manager, чтобы открыть диалоговое окно Configuration Manager.
- В раскрывающемся списке Active Solution Platform выберите параметр, чтобы открыть диалоговое окно New Solution Platform.
- В раскрывающемся списке Тип или выберите новую платформу выберите 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, затем повторно установите параметр гибридной компиляции. Тогда вы увидите успех.
В 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:
- Загружаем программу Restoro PC Repair Tool. Лучше это делать с официального сайта .
- Устанавливаем и запускаем софт. Нажимаем на кнопку «Начать сканирование» (Start Scan).
- После процедуры анализа системы кликаем по клавише «Восстановить все» (Repair All).
Важное достоинство программы – она оптимизирует компьютер, увеличивая его производительность (если в системе есть какие-то проблемы с DLL). Ее можно оставить в качестве настольного софта, так как утилита решает большой спектр проблем.
Способ 2: временно отключаем антивирус
Есть большая вероятность, что ошибка 126 спровоцирована антивирусной защитой системы. Если в момент установки программы антивирус посчитал один из компонентов угрозой и заблокировал его, он будет отсутствовать, а система писать «Не найден указанный модуль». В целом желательно отключать защиту в момент установки программ, которым доверяем.
- Выключаем антивирус (встроенный Защитник Windows и/или сторонний).
- Полностью удаляем программу через «Программы и компоненты» (пункт находится в Панели управления).
- Начинаем установку утилиты снова, проверив, что сейчас антивирус не работает.
- Проверяем результат.
Если сейчас программа заработала нормально, рекомендуем открыть антивирус и добавить в список его исключений данный софт. В противном случае со временем ошибка может вернуться, ведь антивирусная защита снова может заблокировать или удалить файл.
Важно! Для максимального результата лучше сделать полное удаление программы. Для этого можем воспользоваться 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-файлами.
Как запустить системные файлы:
- В поиск Windows вводим cmd и запускаем «Командную строку».
- Вводим команду sfc /scannow.
- Ждем завершения сканирования системы. Все ошибки должны быть исправлены автоматически, если такая возможность есть.
Способ 6: восстанавливаем системные реестр
Ошибка 126 и 127 может быть следствием скопления мусора в реестре или повреждения значений в нем. Одна проблема – вручную все перелистать и исправить просто нереально. Для этого лучше использовать специальные программы, например, Total System Care . В утилите есть все необходимое для анализа системного реестра, его оптимизации и исправления существующих проблем. Еще можем порекомендовать CCleaner . Обе программы справятся со своими задачами.
Способ 7: делаем откат Windows
Если никакие ручные способы исправления не помогают, что бывает редко, приходится обратиться к последнему методу и откатить Windows к последнему рабочему состоянию. Иногда файлы DLL могут пропадать из-за удаления программы, и вы можете столкнуться с ошибкой 126. Чтобы устранить ее, воспользуйтесь точками восстановления. Найти «Параметры восстановления» можем через поиск в Windows.
Теперь ошибка с кодом 126 больше не должна беспокоить пользователя как в Windows 7, так и 8, 10. Одна из процедур практически 100% должна исправить проблему. При этом мы не рекомендуем вручную менять DLL-файл, если удалось обнаружить в каком именно проблема. Все из-за чрезмерно высокого шанса загрузить вирус.
Источник
Im trying to run sample app from wxFreeChart library. After compilation on linking there is an error:
wxcode_msw28d_freechart.lib(wxfreechart_lib_xydataset.obj) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'
I tried to switch linker optionadvancedtarget machine to MachineX64 but it doesnt work.
Im using visual studio 2008, any suggestion ?
thanks for help
asked May 17, 2010 at 13:45
5
The error is explicit, you are trying to link libraries that were compiled with different CPU targets. An executable image can only contain pure x86 (32-bit) or pure x64 (64-bit) code. Mixing is not possible.
You change the target CPU by creating a new configuration for the project, only changing the linker setting isn’t enough. Build + Configuration Manager, Active solution platform combo on upper right, choose New and select x64. That creates a new configuration with several modified project settings, most importantly the compiler that will be used.
Beware that prior to VS2010, the 64-bit compilers are not installed by default. If you don’t see x64 in the platform combo then you’ll need to re-run setup.exe and turn on the option to install the 64-bit compilers. Then also re-run any service pack installer you may have applied.
A possible approach with less pain points is to use the 32-bit version of the library.
answered May 17, 2010 at 15:44
Hans PassantHans Passant
913k145 gold badges1671 silver badges2507 bronze badges
4
I bumped into this too and found a solution.
First on how I got into this problem. I have a project which builds in x86. Then I used the Configuration Manager to add x64, and I hit this problem.
By looking at BuildLog.htm carefully, I saw both of these listed as linker options:
/MACHINE:X64
/machine:X86
I could not find anywhere in the Property Pages dialog where I could change this, so I opened up the .vcproj file and looked for the appropriate line and changed it to:
AdditionalOptions=" /STACK:10000000 /machine:x64 /debug"
and problem solved.
LoneWanderer
2,8981 gold badge22 silver badges41 bronze badges
answered Nov 18, 2011 at 22:09
l00g33kl00g33k
1811 silver badge2 bronze badges
3
Go to project properties-> configuration properties -> Librarian
Set Target Machine to MachineX64 (/MACHINE:X64)
answered Jan 19, 2014 at 14:19
JosephJoseph
1,6663 gold badges22 silver badges41 bronze badges
0
Since the problem is due to the difference in compilation and target machine specifications (x86 & x64) Follow the steps below:
- Open the C++ project that you want to configure.
- Choose the Configuration Manager button to open the Configuration Manager dialog box.
- In the Active Solution Platform drop-down list, select the option to open the New Solution Platform dialog box.
- In the Type or select the new platform drop-down list, select a 64-bit platform.
This solved my problem.
answered May 13, 2014 at 21:00
habhab
6172 gold badges8 silver badges20 bronze badges
Try changing every occurence of .Release into .x64Release in the x64 properties. At least this worked for me…
answered Dec 23, 2010 at 2:39
I know this is a bit old, but I thought I would provide another tip.
In my situation, I inherited this application that I had to maintain.
The VS2008 project came with the same string in C/C++->OutputFIles->»ObjectFIleName» and «Program Database File Name» (for both platforms Win32 and x64).
So when I built Win32 platform, it built fine, but when I tried to build x64, I got the error:
Debug64Objectscommon.obj : fatal error LNK1112: module machine type ‘X86’ conflicts with target machine type ‘x64’
Obviously, both patforms were storing common.obj at the same location, so when I tried to build x64, the linker took the existing object file, which was x86.
To fix I just replaced the existing string with the macro «$(IntDir)» for x64 (no quotes), and made sure that the macro resolved to the correct path, as in the rest of the projects.
That solved my problem.
answered May 24, 2012 at 23:02
falconKfalconK
2711 gold badge2 silver badges11 bronze badges
An update to i00g’s and Thomas’ answers, this time for VS2012 (some names have changed). After copying x86 settings over into an x64 target with the configuration manager, you’ll have the problem for the same reason as was the case earlier (lib targets aren’t correct in the x64 config). Open your .vcxproj (text editor) and replace MachineX86 with MachineX64 where appropriate. (I still haven’t found where this is on the property sheets….) This only seems to be necessary with static libs.
answered Aug 30, 2012 at 2:44
before going for the step «compile -DIPLIB=NONE filename.cxx»
take the path of VIsual Studio installation upto the vcvarsall batch file and change the configuration as shown below.
*C:appsMVS9VCvcvarsall.bat x86_amd64*
now next step should be
compile -64bit -DIPLIB=none filename.cxx
this solved the problem for me
answered Apr 4, 2013 at 9:22
Thanks for the answers guys. My problem was that I changed a x64 solution in Visual Studio to 32 bit in the Configuration Manager only. I ended up just creating a new solution as 32 bit and then copying my C++ code and this error was gone. I think l00g33k and RogerAttrill’s suggestions may have been the solution, but mine worked, too.
answered Jul 8, 2015 at 22:56
JoeCJoeC
712 silver badges6 bronze badges
Recently,I also encountered this problem. That’s because I used qt(x64) in vs win32. If you want to use qt application x64, you could choose vs x64—as the above. If you want to use win32 and perhaps you haven’t,you need to download qt(32bit),then correctly set your enviroment, such as the lib directory, etc.(note: maybe you are is old set in x64(other version), if you convert your win32 or x64 into another, Additional Dependencies includes the old directory!)
Theresa
3,41510 gold badges44 silver badges47 bronze badges
answered Aug 19, 2016 at 0:56
Crawl.WCrawl.W
4034 silver badges17 bronze badges
This problem has nothing to do with the linker, so modifying it’s setting won’t affect the outcome. You’re getting this because I assume you’re trying to target x86 but for one reason or another wxcode_msw28d_freechart.lib is being built as an x64 file.
Try looking at wxcode_msw28d_freechart.lib and whatever source code it derives from. Your problem is happening there. See if there are some special build steps that are using the wrong set of tools (x64 instead of x86).
answered Jan 29, 2017 at 8:21
building on these answers — i also had to modify an X86 reference under Librarian -> Command Line -> Additional Options (for the x64 Platform)
answered Nov 26, 2018 at 20:05
Im trying to run sample app from wxFreeChart library. After compilation on linking there is an error:
wxcode_msw28d_freechart.lib(wxfreechart_lib_xydataset.obj) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'
I tried to switch linker optionadvancedtarget machine to MachineX64 but it doesnt work.
Im using visual studio 2008, any suggestion ?
thanks for help
asked May 17, 2010 at 13:45
5
The error is explicit, you are trying to link libraries that were compiled with different CPU targets. An executable image can only contain pure x86 (32-bit) or pure x64 (64-bit) code. Mixing is not possible.
You change the target CPU by creating a new configuration for the project, only changing the linker setting isn’t enough. Build + Configuration Manager, Active solution platform combo on upper right, choose New and select x64. That creates a new configuration with several modified project settings, most importantly the compiler that will be used.
Beware that prior to VS2010, the 64-bit compilers are not installed by default. If you don’t see x64 in the platform combo then you’ll need to re-run setup.exe and turn on the option to install the 64-bit compilers. Then also re-run any service pack installer you may have applied.
A possible approach with less pain points is to use the 32-bit version of the library.
answered May 17, 2010 at 15:44
Hans PassantHans Passant
913k145 gold badges1671 silver badges2507 bronze badges
4
I bumped into this too and found a solution.
First on how I got into this problem. I have a project which builds in x86. Then I used the Configuration Manager to add x64, and I hit this problem.
By looking at BuildLog.htm carefully, I saw both of these listed as linker options:
/MACHINE:X64
/machine:X86
I could not find anywhere in the Property Pages dialog where I could change this, so I opened up the .vcproj file and looked for the appropriate line and changed it to:
AdditionalOptions=" /STACK:10000000 /machine:x64 /debug"
and problem solved.
LoneWanderer
2,8981 gold badge22 silver badges41 bronze badges
answered Nov 18, 2011 at 22:09
l00g33kl00g33k
1811 silver badge2 bronze badges
3
Go to project properties-> configuration properties -> Librarian
Set Target Machine to MachineX64 (/MACHINE:X64)
answered Jan 19, 2014 at 14:19
JosephJoseph
1,6663 gold badges22 silver badges41 bronze badges
0
Since the problem is due to the difference in compilation and target machine specifications (x86 & x64) Follow the steps below:
- Open the C++ project that you want to configure.
- Choose the Configuration Manager button to open the Configuration Manager dialog box.
- In the Active Solution Platform drop-down list, select the option to open the New Solution Platform dialog box.
- In the Type or select the new platform drop-down list, select a 64-bit platform.
This solved my problem.
answered May 13, 2014 at 21:00
habhab
6172 gold badges8 silver badges20 bronze badges
Try changing every occurence of .Release into .x64Release in the x64 properties. At least this worked for me…
answered Dec 23, 2010 at 2:39
I know this is a bit old, but I thought I would provide another tip.
In my situation, I inherited this application that I had to maintain.
The VS2008 project came with the same string in C/C++->OutputFIles->»ObjectFIleName» and «Program Database File Name» (for both platforms Win32 and x64).
So when I built Win32 platform, it built fine, but when I tried to build x64, I got the error:
Debug64Objectscommon.obj : fatal error LNK1112: module machine type ‘X86’ conflicts with target machine type ‘x64’
Obviously, both patforms were storing common.obj at the same location, so when I tried to build x64, the linker took the existing object file, which was x86.
To fix I just replaced the existing string with the macro «$(IntDir)» for x64 (no quotes), and made sure that the macro resolved to the correct path, as in the rest of the projects.
That solved my problem.
answered May 24, 2012 at 23:02
falconKfalconK
2711 gold badge2 silver badges11 bronze badges
An update to i00g’s and Thomas’ answers, this time for VS2012 (some names have changed). After copying x86 settings over into an x64 target with the configuration manager, you’ll have the problem for the same reason as was the case earlier (lib targets aren’t correct in the x64 config). Open your .vcxproj (text editor) and replace MachineX86 with MachineX64 where appropriate. (I still haven’t found where this is on the property sheets….) This only seems to be necessary with static libs.
answered Aug 30, 2012 at 2:44
before going for the step «compile -DIPLIB=NONE filename.cxx»
take the path of VIsual Studio installation upto the vcvarsall batch file and change the configuration as shown below.
*C:appsMVS9VCvcvarsall.bat x86_amd64*
now next step should be
compile -64bit -DIPLIB=none filename.cxx
this solved the problem for me
answered Apr 4, 2013 at 9:22
Thanks for the answers guys. My problem was that I changed a x64 solution in Visual Studio to 32 bit in the Configuration Manager only. I ended up just creating a new solution as 32 bit and then copying my C++ code and this error was gone. I think l00g33k and RogerAttrill’s suggestions may have been the solution, but mine worked, too.
answered Jul 8, 2015 at 22:56
JoeCJoeC
712 silver badges6 bronze badges
Recently,I also encountered this problem. That’s because I used qt(x64) in vs win32. If you want to use qt application x64, you could choose vs x64—as the above. If you want to use win32 and perhaps you haven’t,you need to download qt(32bit),then correctly set your enviroment, such as the lib directory, etc.(note: maybe you are is old set in x64(other version), if you convert your win32 or x64 into another, Additional Dependencies includes the old directory!)
Theresa
3,41510 gold badges44 silver badges47 bronze badges
answered Aug 19, 2016 at 0:56
Crawl.WCrawl.W
4034 silver badges17 bronze badges
This problem has nothing to do with the linker, so modifying it’s setting won’t affect the outcome. You’re getting this because I assume you’re trying to target x86 but for one reason or another wxcode_msw28d_freechart.lib is being built as an x64 file.
Try looking at wxcode_msw28d_freechart.lib and whatever source code it derives from. Your problem is happening there. See if there are some special build steps that are using the wrong set of tools (x64 instead of x86).
answered Jan 29, 2017 at 8:21
building on these answers — i also had to modify an X86 reference under Librarian -> Command Line -> Additional Options (for the x64 Platform)
answered Nov 26, 2018 at 20:05
Содержание
- Фатальная ошибка LNK1112: тип модуля модуля «x64» конфликтует с типом целевой машины «X86»
- Русские Блоги
- Описание проблемы
- Решения
- Интеллектуальная рекомендация
- Процесс совместной разработки с использованием многопользовательского проекта Gitee
- Решить проблемы, возникающие при компиляции nginx
- Расширенное использование WPF ListBox (два)
- Примеры шаблонов-примеров адаптеров
- Три технологии кеша
- Fatal error lnk1112 тип компьютера модуля x86 противоречит типу целевого компьютера x64
- Answered by:
- Question
- Answers
- Фатальная ошибка LNK1112: тип модуля модуля «X86» конфликтует с типом целевой машины «AMD64»
- Фатальная ошибка LNK1112: тип компьютера модуля «x64» конфликтует с типом машины назначения «X86»
- 29 ответов
Фатальная ошибка LNK1112: тип модуля модуля «x64» конфликтует с типом целевой машины «X86»
Я использую CUDA (VС++, Visual studio 2008sp1) для отладки программы FEM. Программа может работать только на платформе Win32, для недостаточности cuda. Я думаю, что связанные с библиотекой файлы скомпилированы на платформе x86, но когда я ее компилирую, я получаю сообщение об ошибке “Неустранимая ошибка LNK1112: тип машинного модуля” x64 “конфликтует с типом целевой машины” X86 “.
Я попытался преобразовать платформу в x64, но это не сработало. Скажите, пожалуйста, что такое “тип модульной машины” и что такое “тип целевой машины”? Как я могу его преодолеть?
Я написал запись в блоге об этом, когда столкнулся с этой сводящей с ума проблемой, и наконец вернул мою систему в рабочее состояние.
Вот что нужно проверить в следующем порядке:
Проверьте параметры свойств в настройках компоновщика по адресу: Свойства> Свойства конфигурации> Компоновщик> Дополнительно> Целевой компьютер. Выберите MachineX64, если вы используете 64-битную сборку, или MachineX86, если вы делаете 32-битную сборку.
В Visual Studio выберите Инструменты> Параметры в главном меню. выберите Проекты и решения> VC++ Каталоги. Выберите x64 из раскрывающегося списка Платформа. Убедитесь, что первая запись: $ (VCInstallDir)binx86_amd64, за которой следует $ (VCInstallDir)bin.
Как только я сделал шаг 4, все снова заработало для меня. Дело в том, что я сталкивался с этой проблемой во всех моих проектах, где я хотел скомпилировать в направлении 64-битной цели.
В дополнение к списку С. Джонсона я бы добавил следующее:
Проверьте в Visual Studio:
Свойства проекта → Свойства конфигурации → Компоновщик → Командная строка.
“Дополнительные параметры” НЕ должны содержать /machine:X86
У меня есть такой ключ, сгенерированный выводом CMake: CMake сгенерировал проект x86, затем я добавил платформу x64 через Configuration Manager в Visual Studio 2010 – все было прекрасно создано для новой платформы, за исключением командной строки компоновщика, указано /machine:X86 отдельно.
У меня возникла такая же проблема в VS2008, когда я попытался добавить сборку X64 в проект, преобразованный из VS2003.
Я просмотрел все, что было обнаружено при поиске этой ошибки в Google (целевой компьютер, каталоги VС++, DUMPBIN….), и все выглядело нормально.
Наконец, я создал новый тестовый проект и сделал те же изменения, и он, похоже, сработал.
Выполнение разницы между файлами vcproj показало проблему….
Мой преобразованный проект имел /MACHINE: i386 установлен как дополнительная опция, установленная в Linker- > Command Line. Таким образом, были установлены два параметра /MACHINE (как x64, так и i386), а дополнительный – предпочтение.
Удаление и правильная настройка в Linker- > Advanced- > Target Machine устранили проблему.
Быстрый поиск/замена для всех событий (десять отдельных параметров файла) устранил проблему.
Поскольку проблема связана с различием в спецификации компиляции и целевой машины (x86 и x64)
Выполните следующие шаги:
Он решил мою проблему.
В Visual Studio 2012 +/- на странице свойств “Свойства конфигурации”.Linker. “Командная строка” содержит поле с надписью “Дополнительные параметры”. Если вы создаете x64, убедитесь, что в поле не содержится /MACHINE: I386. Мои проекты выполнялись, и это породило ошибку, о которой идет речь.
Я столкнулся с этой проблемой при построении QT. В инструкциях, которые я читал, я предложил настроить nmake с помощью командной строки VS.
Я выбрал командную строку x64 и выполнил настройку без особых проблем. Когда я попробовал nmake, он дал эту ошибку.
Я думаю, что некоторые из компонентов были предварительно построены для 32-битных. Ошибка даже сообщила, какие модули были построены для x86.
Я использовал 32-битную командную строку по умолчанию VS, и она сработала.
В Visual Studio 2013,
1) Проверьте страницы свойств проекта/свойства конфигурации/компоновщик/все параметры и исправьте все пропущенные машины и каталоги.
2) Проверьте страницы свойств проекта/свойства конфигурации/компоновщик/ввод и исправьте все пропущенные настроенные каталоги.
См. пример 1)
Подсказка в журнале компиляции.
Вот так:
Это «-machine 32» является проблемой.
Первый набор 64-битной опции компиляции,
следующий параметр настройки гибридной компиляции.
Тогда u может видеть успешное выполнение.
Если ваше решение имеет проекты lib, проверьте свойство Target Machine в Property- > Librarian- > General
В дополнение к списку Jhonson также проверяйте папки библиотек
В визуальной студии выберите “Инструменты” > “Параметры” в главном меню. выберите “Проекты и решения” > “Каталоги VС++”. Выберите x64 в раскрывающемся списке “Платформа”.
Это случилось со мной сегодня, потому что я добавил каталог библиотеки в режиме x86 и случайно удалил унаследованные каталоги, сделав их жестко закодированными.
Затем, перейдя на x64, мои VС++-каталоги все еще читают:
Я использовал CMake, а затем добавил конфигурацию win32. На странице свойств было показано x86, но при открытии файла vcxproj в текстовом редакторе было x64! Ручное изменение на x86 решило это.
Это очень неприятная и неприятная проблема, но как только вы ее понимаете, это довольно просто: у вас есть какой-то элемент в вашей сборке, который создает один тип архитектуры (в вашем случае x64), несмотря на то, что он был целью для другого типа (скажем, x86).
Вы можете проанализировать источник своей проблемы, посмотрев, какой файл obj вызывает сбои и начинает искать проблему. Каждый obj будет иметь аналог исходного кода: либо в cpp, c, asm и т.д. Вокруг него могут быть специальные события сборки, которые используют неправильный инструмент. Проверьте это в листах свойств.
Я бы посмотрел там сначала, прежде чем переходить к списку дел Джонсона.
Файл vcxproj может содержать “MACHINE: i386”
Отредактируйте файл vcxproj с помощью редактора. удалите его!

Тип модуля модуля – это машина, на которой вы компилируете, а тип целевой машины – это архитектура x86 или x64, для которой вы создаете свои двоичные файлы.
Эта проблема также может возникнуть, если ваш проект настроен на наличие одинаковых промежуточных каталогов в свойствах проекта → Свойства конфигурации → Общие
Прежде всего, попробуйте следующее:
1. goto Configuration Manager и создайте новый 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 prompt)
это может быть полезно:
Кроме того, если вам это нравится:
CL “% 1% 2% 3″/EHsc/link user32.lib Gdi32.lib Winmm.lib comctl32.lib *.obj/SUBSYSTEM: CONSOLE/MACHINE: x86
Вы должны del *.obj до; чтобы не путать компоновщик с 64- и 32-битными объектами, оставшимися от предыдущих компиляций?
что такое ОС? если это окно x64, то вам нужно убедиться, что CUDA x64 установлен и, следовательно, VS2008 должен скомпилировать проект в режиме x64…
Источник
Русские Блоги
Описание проблемы
win10 64 vs 2013 Произошла следующая ошибка: «ошибка LNK1112: тип компьютера модуля« X86 »конфликтует с типом компьютера назначения« x64 »;
Решения
Есть две вещи, которые нужно установить:
1. Щелкните правой кнопкой мыши проект, выберите «Свойства», нажмите «Configuration Manager» вверху, создайте новую платформу «win32», затем выберите win32 в качестве активной платформы решения и нажмите «Закрыть».
Восстановить решение и решить проблему!
Описание: поскольку мы создаем 32-разрядный проект, а компьютерная система является 64-разрядной, платформой проекта является «win32», а целевой компьютер изменяется на «x86», как показано ниже:
Примечание. Если описанный выше метод не удался, щелкните правой кнопкой мыши проект и выберите «Чистое решение», а затем выполните перестройку в соответствии с приведенной выше конфигурацией.
Примечание. Следует также обратить внимание на разработку платформы X64: если вы занимаетесь разработкой 64-битной версии, файлы DLL, на которые есть ссылки в проекте, не могут быть 32-битными файлами DLL, иначе во время работы произойдет ошибка.
То же самое относится и к 32-битной разработке. На 64-битные DLL-файлы нельзя ссылаться.
Интеллектуальная рекомендация
Процесс совместной разработки с использованием многопользовательского проекта Gitee
Процесс совместной разработки нескольких человек Step0 Все члены команды регистрируют аккаунт на Gitee http://gitee.com Шаг 1 Руководитель группы создает такой проект, как: CoperationDemo Шаг 2 Руково.
Решить проблемы, возникающие при компиляции nginx
Из-за потребностей проекта мы собираемся установить nginx на новый сервер, и нам нужно установить два расширения pcre и zlib. Поскольку это относительно просто, я не буду вдаваться в подробности здесь.
Расширенное использование WPF ListBox (два)
Он часто используется в проектах для запроса данных на основе критериев поиска, а затем использования карточек для отображения данных. При использовании карточек для отображения данных ширина интерфей.
Примеры шаблонов-примеров адаптеров
Сценарий: после того, как мобильный телефон пройдет зарядное устройство, обычный блок питания от 220 В до 4 В Описание: 220В бытовой электроэнергии не может напрямую зарядить мобильный телефон, вам ну.
Три технологии кеша
Три технологии кеша Три технологии кеша Кэш браузера Кэш программы OB буфер 1. Кэш браузера, кэш программы, CACHE Кэш браузера: Браузер принимает данные, возвращаемые сервером, и на странице отображае.
Источник
Fatal error lnk1112 тип компьютера модуля x86 противоречит типу целевого компьютера x64
This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.
Answered by:
Question
I am having vc++ project. I am trying to build it as 64 bit using Visual Studio 2010 ultimate trial. But I am getting an error: «module machine type ‘X86’ conflicts with target machine type ‘x64′».
My machine is Windows 7 (32 bit). And I have installed the 64 bit compiler.
This project was getting build as both x86 and x64 on Visual Studio 2010 Professional. I am confused.
I have created a simple win32 console project and tried it to build for 64 bit, but I still get the same error.
Is there anything else i need to install?
Answers
It is a known problem that on occasions VC picks up certain settings from older versions of VC installed and causes these kinds of problems.
What you should do is reset the settings for Visual Studio.
Go to Tools->Import and Export Settings and on the wizard that appears select Reset all settings. On the next page choose what you want, and then on the final page, select the settings that you want, and if it offers to allow you to migrate elegable settings from previous versions of Visual Studio, make sure that it is not selected. Then click finish.
After the VS settings are reset, try creating a new project and seeing how things turn out.
If this doesn’t work, open a Visual Studio command prompt, and on the command line run devenv /ResetUserData then run Visual Studio again. It will be like the very first time you run Visual Studio. Again, choose the environment that you want, and if it gives you the option to migrate elegable settings, make sure you don’t. Then try a project again.
One of these should work, but please note that you must not migrate any settings from previous versions of Visual Studio.
This is a signature
Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.
Do you want Visual Studio 11 Express to be freely installable on Windows 7 and able to write regular C++ applications? Please vote for this.
Источник
Фатальная ошибка LNK1112: тип модуля модуля «X86» конфликтует с типом целевой машины «AMD64»
Я использую VS 2003.Net на 32-битной ОС XP. Я также установил «Microsoft Platform SDK» на свою машину. Могу ли я создать приложение vС++ (двоичные файлы), предназначенное для 64-разрядной ОС?
Я использую следующие параметры проекта:
Я получаю следующую ошибку:
Нужно ли мне создавать проект на 64-битной ОС или мне нужно изменить настройки проекта, чтобы устранить эту ошибку.
Пожалуйста, помогите мне решить эту проблему.
У меня была такая же проблема сегодня, вот как я ее решил (в Visual Studio 2008):
Пошел в Project Properties → Linker → Command Line → Additional Options и удалил /MACHINE: I386 из дополнительных опций компоновщика.
Надеюсь, что это поможет
Для 64-разрядных пользователей Windows:
У меня была такая же проблема сегодня, вот как я ее решил (в Visual Studio 2008): я пошел к:
и добавил /MACHINE:I364 из дополнительных опций компоновщика.
Это сработало для меня.
Имея ту же проблему в VS2008. Мое решение состояло в том, чтобы сменить платформу активного решения, расположенную в Build → Configuration Manager, и создать новую платформу решений с помощью x64 и сопоставить настройки с Win32. Это позволило мне использовать 32-битные библиотеки pre-build в моей 64-битной ОС.
Я столкнулся с ошибкой, когда пытался создать свою собственную библиотеку для ARM64 в Visual Studio 2017. И моя целевая машина была уже ARM64, как и ожидалось.
Это было разрешено, добавив
в файл проекта.
После всего вышеизложенного я мог бы успешно создать свой проект в ARM64.
Надеюсь, это будет полезно.
Вы смотрите на имя файла obj, и вы найдете там корень своей проблемы. Независимо от того, что указатель obj будет иметь какой-то аналоговый код исходного кода с тем же именем. Посмотрите на нее и посмотрите, как она компилируется. Обычно все это происходит автоматически в VS, но иногда есть специальные шаги сборки, которые были добавлены разработчиком. Осмотрите пользовательские, предварительные и последующие события, чтобы увидеть, используется ли инструмент x86 для его сборки. Лист свойств в VS2010 + будет специфичен для obj и платформы, поэтому вы можете проверить библиотеки, используемые для проверки того, что они не являются 32-разрядными.
Источник
Фатальная ошибка LNK1112: тип компьютера модуля «x64» конфликтует с типом машины назначения «X86»
Я использую CUDA (VC++, Visual studio 2008sp1) для отладки программы FEM. Программа может работать только на платформе Win32, из-за недостатка cuda. Я думаю, что все связанные библиотечные файлы скомпилированы на платформе x86, но когда я скомпилирую их, я получаю сообщение об ошибке «Неустранимая ошибка LNK1112: тип машины модуля» x64 «конфликтует с типом целевой машины» X86 «».
Я пытался преобразовать платформу в x64, но это не сработало. Скажите, пожалуйста: что такое «тип машины модуля» и что такое «тип машины цели»? Как я могу преодолеть это?
29 ответов
Я написал запись в блоге об этом, когда столкнулся с этой сводящей с ума проблемой, и наконец вернул мою систему в рабочее состояние.
Вот что нужно проверить в следующем порядке:
Проверьте параметры свойств в настройках компоновщика по адресу: Свойства> Свойства конфигурации> Компоновщик> Дополнительно> Целевой компьютер. Выберите MachineX64, если вы используете 64-битную сборку, или MachineX86, если вы делаете 32-битную сборку.
В Visual Studio выберите Инструменты> Параметры в главном меню. выберите Проекты и решения> Каталоги VC++. Выберите x64 из раскрывающегося списка Платформа. Убедитесь, что первая запись: $ (VCInstallDir) bin x86_amd64, за которой следует $ (VCInstallDir) bin.
Как только я сделал шаг 4, все снова заработало для меня. Дело в том, что я сталкивался с этой проблемой во всех моих проектах, где я хотел скомпилировать в направлении 64-битной цели.
Источник





Создать запись «Двигатель», которая содержит элементы «Название», «Мощность», «Скорость», «Цена»










