Come risolvere il tipo di macchina del modulo 'X86' in conflitto con il tipo di macchina di destinazione 'x64' Visual Studio

Question

Sto compilando la libreria Openssl che devo usare nello script python. Sto usando il prompt dei comandi dello sviluppatore di Visual Studio 2015. La mia macchina è Windows 7 64-bit.

Quando digito il comando: nmake -f ms\ntdll.mak

ottengo questo errore:

tmp32dll\uplink.obj : fatal error LNK1112: module machine type 'X86' conflicts w 
ith target machine type 'x64' 
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0 
\VC\BIN\amd64_arm\link.EXE"' : return code '0x458' 
Stop. 

Ho cercato e diverse soluzioni per problema simile suggeriscono cambiare la piattaforma del progetto dalle impostazioni del progetto. Non ho un progetto VS. Sto eseguendo tutti questi comandi solo per compilare la libreria OpenSSL. Sto usando il comando VS.

Per favore, aiutatemi.

Answer 1

Questo errore indica che tmp32dll\uplink.obj è un file binario a 32 bit mentre il linker prevede che sia a 64 bit poiché è destinato a 64 bit.

Sembra che è necessario ri-compilarlo come a 64-bit, o semplicemente eseguire un rebuild-tutti (o cancellare tutti *.obj o anche l'intero directory di output binario)

Questo può accadere se il processo di compilazione è interrotto, quindi si modifica la piattaforma di destinazione e quindi si ripete il processo di compilazione in modo incrementale. I 32 bit non si combinano con i 64 bit, quindi è completamente o in un modo o nell'altro.

Answer 2

Ho riscontrato lo stesso problema, solo con VS2013.

Ci sono 2 approcci che mi sono imbattuto, che può o non può essere utile nel vostro caso:

il primo approccio

(Può essere rilevante solo per le versioni VS2013 e superiori)

Aprire il prompt dei comandi degli strumenti nativi di VS2015 x64 ed eseguire il comando lì.

Note: 
If you get the opposite message: 
module machine type 'x64' conflicts with target machine type 'x86' 
then you should open the 'VS2015 x86 Native Tools Command Prompt' 

Entrambi gli strumenti si trovano nella cartella:

C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\Shortcuts

Il secondo approccio

(Può essere rilevante solo per le versioni precedenti alla VS2013)

In il Prompt dei comandi dello sviluppatore per VS2015 è possibile modificare la piattaforma di destinazione del compilatore eseguendo runnin g il seguente comando

"C:\Program Files (x86)\Microsoft Visual Studio 15.0\VC\vcvarsall.bat x64"

"C:\Program Files (x86)\Microsoft Visual Studio [VS Version]\VC\vcvarsall.bat [Target Platform]"

Per VS 2017

"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvarsall.bat [Target Platform]"

Note: 
VS Version: 10.0|11.0|12.0|15.0|... 
Target Platform: x86|amd64|x64|arm|x86_arm|x86_amd64|amd64_x86|amd64_arm|amd64_x86 
*leaving the target platform empty will default to x86 

Answer 3

Questo errore si causa un componente specifico nella build viene compilato come un binario 86 anziché x64 (l'architettura della macchina di destinazione) - in pratica stai dando al linker un pezzo di puzzle quadrato e dicendolo per adattarlo a un buco circolare.

Nel tuo caso:

tmp32dll\uplink.obj : fatal error LNK1112: module machine type 'X86' conflicts w 
ith target machine type 'x64' 
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0 
\VC\BIN\amd64_arm\link.EXE"' : return code '0x458' 
Stop. 

Si guarda il nome del file obj che causa l'errore: uplink.obj, quindi si guarda uplink.cpp (o uplink.asm o uplink.whatever) e ispezionare come viene compilato. Di solito tutta questa roba è automatizzata in VS, ma a volte ci sono passaggi di build speciali che sono stati aggiunti dallo sviluppatore. Ispezionare gli eventi personalizzati, pre e post-build per verificare se uno strumento x86 viene utilizzato per assemblarlo.

Nel mio caso, stavo cercando di compilare 7zip in x64 usando Visual Studio 8 e tutto stava compilando eccetto per le macro di assembly (asm), che stavano compilando in x86 e rompendo il processo di compilazione. Ho scoperto che VS stava provando a usare ml.exe per compilarli invece di ml64.exe guardando il foglio delle proprietà di asm. Nel mio caso ho cambiato la chiamata a ml64.exe per eliminare questo errore (ho anche dovuto modificare i file asm per essere a 64 bit solo eliminando tutto il codice x86 ma questa è un'altra storia).