erreur fatale LNK1112: le type de machine du module 'x64' est en conflit avec le type de machine cible 'X86'

J'utilise CUDA (VC ++, Visual studio 2008sp1) pour déboguer un programme FEM. Le programme ne peut fonctionner que sur une plate-forme Win32, faute de cuda. Je pense que les fichiers de bibliothèque liés sont tous compilés sur la plate-forme x86, mais lorsque je le compile, j'obtiens le message d'erreur "erreur fatale LNK1112: le type de machine du module" x64 "est en conflit avec le type de machine cible" X86 "".

J'ai essayé de convertir la plate-forme en x64, mais cela n'a pas fonctionné. Veuillez me dire: qu'est-ce que le «type de machine module» et qu'est-ce que le «type de machine cible»? Comment puis-je le surmonter?

J'ai écrit une entrée de blog à ce sujet, car j'ai rencontré ce problème exaspérant, et j'ai finalement remis mon système en état de marche.

Voici les éléments à vérifier, dans cet ordre:

1. Vérifiez vos options de propriétés dans les paramètres de l'éditeur de liens sous: Propriétés> Propriétés de configuration> Éditeur de liens> Avancé> Machine cible. Sélectionnez MachineX64 si vous ciblez une version 64 bits ou MachineX86 si vous créez une version 32 bits.

2. Sélectionnez Build> Configuration Manager dans le menu principal de Visual Studio. Assurez-vous que votre projet a la plate-forme correcte spécifiée. Il est possible que l'EDI soit configuré pour générer x64, mais un projet individuel de la solution peut être défini pour cibler win32. Alors oui, le studio visuel laisse beaucoup de corde pour se pendre, mais c'est la vie.

3. Vérifiez que vos fichiers de bibliothèque sont vraiment du type de plate-forme que vous ciblez. Cela peut être utilisé en utilisant dumpbin.exe qui se trouve dans votre répertoire Visual Studio VC \ bin. utilisez l'option -headers pour vider toutes vos fonctions. Recherchez l'entrée machine pour chaque fonction. il devrait inclure x64 s'il s'agit d'une version 64 bits.

4. Dans Visual Studio, sélectionnez Outils> Options dans le menu principal. sélectionnez Projets et solutions> Répertoires VC ++. Sélectionnez x64 dans la liste déroulante Plate-forme. Assurez-vous que la première entrée est: $ (VCInstallDir) \ bin \ x86_amd64 suivi de $ (VCInstallDir) \ bin .

Une fois que j'ai fait l'étape 4, tout a fonctionné à nouveau pour moi. Le truc, c'est que je rencontrais ce problème sur tous mes projets où je voulais compiler vers une cible 64 bits.

En plus de la liste de C Johnson , j'ajouterais le point suivant:

Archivez Visual Studio:
Propriétés du projet -> Propriétés de configuration -> Éditeur de liens -> Ligne de commande.

"Options supplémentaires" ne doit PAS contenir /machine:X86

J'ai une telle clé, générée par la sortie CMake: CMake généré projet x86, alors j'ajouté via la plate - forme x64 Configuration Managerdans Visual Studio 2010 - tout a été créé bien pour la nouvelle plate - forme , sauf que la ligne de commande de liaison, indiqué /machine:X86séparément.

J'ai rencontré le même problème dans VS2008 lorsque j'ai essayé d'ajouter une version X64 à un projet converti à partir de VS2003.

J'ai regardé tout ce qui a été trouvé lors de la recherche de cette erreur sur Google (machine cible, répertoires VC ++, DUMPBIN ....) et tout semblait OK.

Enfin, j'ai créé un nouveau projet de test et j'ai fait les mêmes changements et cela a semblé fonctionner.

Faire une différence entre les fichiers vcproj a révélé le problème ...

Mon projet converti avait / MACHINE: i386 défini comme option supplémentaire définie sous Linker-> Command Line. Ainsi, il y avait deux options / MACHINE définies (à la fois x64 et i386) et l'option supplémentaire a eu la préférence.

Le supprimer et le configurer correctement sous Linker-> Advanced-> Target Machine a fait disparaître le problème.

Tous les paramètres du projet semblaient parfaits, mais j'ai toujours l'erreur. L'examen du .vcxprojfichier et la recherche de «x86» ont révélé le problème:

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

Une recherche / remplacement rapide de toutes les occurrences (dix paramètres de fichier individuels) a résolu le problème.

Étant donné que le problème est dû à la différence de compilation et de spécifications de la machine cible (x86 et x64), suivez les étapes ci-dessous:

1. Ouvrez le projet C ++ que vous souhaitez configurer.
2. Cliquez sur le bouton Configuration Manager pour ouvrir la boîte de dialogue Configuration Manager.
3. Dans la liste déroulante Plateforme de solutions actives, sélectionnez l'option permettant d'ouvrir la boîte de dialogue Nouvelle plateforme de solutions.
4. Dans la liste déroulante Type ou sélectionnez la nouvelle plate-forme, sélectionnez une plate-forme 64 bits.

Cela a résolu mon problème.

Vous avez probablement un fichier .OBJ ou .LIB ciblé pour x64 (c'est le type de machine du module) pendant que vous liez pour x86 (c'est le type de machine cible).

Utilisez DUMPBIN / HEADERS sur vos fichiers .OBJ et vérifiez l'entrée de la machine dans le bloc FILE HEADER VALUES.

Dans Visual Studio 2012 +/-, la page de propriétés de «Propriétés de configuration». Linker. «Ligne de commande» contient une zone intitulée «Options supplémentaires». Si vous créez x64, assurez-vous que cette zone ne contient pas / MACHINE: I386. Mes projets l'ont fait et cela a généré l'erreur en question.

Je suis tombé sur ce problème lors de la construction de QT. Les instructions que j'ai lues quelque part suggèrent que je configure nmake à l'aide de l'invite de commande VS.

J'ai choisi l'invite de commande x64 et effectué la configuration sans trop de tracas. Quand j'ai essayé nmake, cela a donné cette erreur.

Je pense que certains des composants ont été pré-construits pour 32 bits. L'erreur a même signalé quels modules ont été construits pour x86.

J'ai utilisé l'invite de commande VS par défaut de 32 bits et cela a fonctionné.

Dans Visual Studio 2013,

1) Vérifiez les pages de propriétés du projet / Propriétés de configuration / Éditeur de liens / Toutes les options et corrigez toutes les machines et répertoires mal configurés.

2) Vérifiez les pages de propriétés du projet / Propriétés de configuration / Éditeur de liens / Entrée et corrigez tous les répertoires configurés manquants.

Voir l'exemple de 1)

Le fichier vcxproj peut contenir 'MACHINE: i386' Editez le fichier vcxproj avec l'éditeur. supprimez-le!

"project property - CUDA Runtime API - GPU - NVCC Compilation Type"

Définissez l'option de compilation 64 bits -m64 -cubin

L'indice est au niveau du journal de compilation. Comme ça:

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

C'est un "-machine 32"problème.

Commencez par définir l'option de compilation 64 bits, puis re-définissez l'option de compilation hybride. Ensuite, vous pouvez voir le succès.

Si votre solution a des projets de bibliothèque, vérifiez la propriété Machine cible dans Propriété-> Bibliothécaire-> Général

En plus de la liste de Jhonson, vérifiez également les dossiers de la bibliothèque

Dans Visual Studio, sélectionnez Outils> Options dans le menu principal. sélectionnez Projets et solutions> Répertoires VC ++. Sélectionnez x64 dans la liste déroulante Plate-forme.

$(VCInstallDir)lib\AMD64;
$(VCInstallDir)atlmfc\lib\amd64;
$(WindowsSdkDir)lib\x64;

Cela m'est arrivé aujourd'hui parce que j'avais ajouté un répertoire de bibliothèque alors que j'étais toujours en mode x86 et que j'avais accidentellement supprimé les répertoires hérités, les rendant codés en dur à la place. Ensuite, après le passage à x64, mes répertoires VC ++ lisent toujours:

"...; $ (VC_LibraryPath_x86); $ (WindowsSDK_LibraryPath_x86);"

au lieu de _x64.

J'utilisais CMake et j'ai ensuite ajouté une configuration win32. La page de propriétés montrait x86 mais en fait, lors de l'ouverture du fichier vcxproj dans un éditeur de texte, c'était x64! Le passage manuel à x86 a résolu ce problème.

C'est un problème très frustrant et ennuyeux, mais une fois que vous l'avez compris, c'est assez simple: vous avez un élément dans la construction d'un type d'architecture (dans votre cas x64) malgré le fait qu'il a été cible pour un autre type (disons x86 ).

Vous pouvez disséquer la source de votre problème en regardant quel fichier obj est à l'origine du plantage et commencer à rechercher le problème. Chaque obj aura un code source analogique: soit dans cpp, c, asm, etc. Il peut y avoir des événements de construction spéciaux autour de lui qui utilisent le mauvais outil. Vérifiez cela dans les feuilles de propriétés.

J'y regarderais d'abord avant de parcourir la liste des choses à faire de C Johnson.

J'ai résolu ce problème en changeant Win32 en * 64 dans Visual Studio 2013.

le type de machine du module est la machine sur laquelle vous compilez et le type de machine cible est l'architecture x86 ou x64 pour laquelle vous construisez vos binaires.

Ce problème peut également se produire si votre projet est configuré pour avoir les mêmes répertoires intermédiaires dans Propriétés du projet -> Propriétés de configuration -> Général

Tout d'abord, essayez les choses suivantes: 1. Accédez à Configuration Manager et créez un nouveau x64 s'il n'y est pas déjà. 2. sélectionnez la solution x64. 3. allez dans les propriétés du projet, puis Linker-> Advanced sélectionnez la machine x64. 4. Recréez maintenant la solution.

Si toujours vous obtenez la même erreur. essayez une solution propre, puis reconstruisez à nouveau et ouvrez Visual Studio, vous obtiendrez la liste des projets récemment ouverts, faites un clic droit sur le projet et supprimez-le de là. Allez maintenant à la solution et rouvrez la solution.

cela m'arrive lorsque je convertis ma solution VS2008 en VS2010 et que je change la configuration de win32 en X64, dans mon ancienne solution, j'ai mfcs90d.lib (Configuration-> Linker-> Input-> Additional dependencies), car j'utilise VS010 je viens de vérifier dans le dossier VS2010 où il est mfcs100d.lib, j'ai donc changé mfcs90d.lib en mfcs100d.lib dans (Configuration-> Linker-> Input-> Additional dependencies) cela fonctionnait bien.

Pour ceux qui utilisent QT Creator, le problème est le même (comme décrit par @ c-johnson). Assurez-vous que les paramètres du compilateur pour MSVC dans votre kit sont définis sur x86 comme indiqué ci-dessous.

pour certains utilisant l'invite de commande (invite DOS), cela peut être utile:

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

Aussi si vous aimez ça:

CL "% 1% 2% 3" / EHsc / link user32.lib Gdi32.lib Winmm.lib comctl32.lib * .obj / SOUS-SYSTÈME: CONSOLE / MACHINE: x86

vous devez supprimer * .obj avant ; pour éviter de confondre l'éditeur de liens avec les objets 64 et 32 ​​bits laissés par les compilations précédentes?

Beaucoup de bonnes suggestions ci-dessus.

Aussi si vous essayez de créer x86 Win32:

Assurez-vous que toutes les bibliothèques auxquelles vous créez un lien dans Program Files (x86) sont en fait des bibliothèques x86 car elles ne sont pas nécessairement ...

Par exemple, un fichier lib auquel j'ai lié dans C: \ Program Files (x86) \ Microsoft Visual Studio \ 2019 \ Professional \ SDK a généré cette erreur, j'ai finalement trouvé une version x86 de celui-ci dans C: \ Program Files (x86) \ Windows Kits \ 10 \ Lib \ 10.0.18362.0 \ um \ x86 et tout fonctionnait bien.

quel est le système d'exploitation? s'il s'agit d'un windows x64 alors vous devez vous assurer que CUDA x64 a été installé et donc que VS2008 doit compiler le projet en mode x64 ...

CUDA installera uniquement x64 OU x86 dans Windows