błąd krytyczny LNK1112: typ maszyny modułu „x64” powoduje konflikt z maszyną docelową „X86”

Używam CUDA (VC ++, Visual studio 2008sp1) do debugowania programu FEM. Program może działać tylko na platformie Win32, z powodu niewystarczalności cuda. Myślę, że wszystkie połączone pliki bibliotek są kompilowane na platformie x86, ale kiedy je kompiluję, pojawia się komunikat o błędzie „błąd krytyczny LNK1112: typ maszyny modułu„ x64 ”powoduje konflikt z maszyną docelową„ X86 ”.

Próbowałem przekonwertować platformę na x64, ale to nie działało. Powiedz mi: co to jest „typ maszyny modułowej”, a co „typ maszyny docelowej”? Jak mogę to pokonać?

Napisałem o tym wpis na blogu , ponieważ napotkałem ten irytujący problem, i w końcu przywróciłem system do stanu gotowości.

Oto rzeczy do sprawdzenia w następującej kolejności:

1. Sprawdź opcje właściwości w ustawieniach linkera na: Właściwości> Właściwości konfiguracji> Linker> Zaawansowane> Maszyna docelowa. Wybierz MachineX64, jeśli celujesz w wersję 64-bitową, lub MachineX86, jeśli tworzysz wersję 32-bitową.

2. Wybierz Kompilacja> Menedżer konfiguracji z menu głównego w Visual Studio. Upewnij się, że Twój projekt ma właściwą platformę. Możliwe jest ustawienie IDE do budowania x64, ale indywidualny projekt w rozwiązaniu można ustawić na docelowy system win32. Tak, studio wizualne pozostawia wiele lin do powieszenia, ale takie jest życie.

3. Sprawdź, czy pliki bibliotek, na które naprawdę są typu platformy, na które są kierowane. Można tego użyć, używając dumpbin.exe, który znajduje się w katalogu programu Visual Studio VC \ bin. użyj opcji -headers, aby zrzucić wszystkie swoje funkcje. Poszukaj wpisu maszyny dla każdej funkcji. powinien zawierać x64, jeśli jest to wersja 64-bitowa.

4. W Visual Studio wybierz Narzędzia> Opcje z menu głównego. wybierz Projekty i rozwiązania> Katalogi VC ++. Wybierz x64 z menu rozwijanego Platforma. Upewnij się, że pierwszy wpis to: $ (VCInstallDir) \ bin \ x86_amd64, a następnie $ (VCInstallDir) \ bin .

Po wykonaniu kroku 4 wszystko znów działało dla mnie. Problem polegał na tym, że napotykałem ten problem we wszystkich moich projektach, w których chciałem się skompilować w kierunku 64-bitowego celu.

Oprócz listy C Johnson dodałbym następujący punkt:

Sprawdź w Visual Studio:
Właściwości projektu -> Właściwości konfiguracji -> Łącznik -> Wiersz poleceń.

„Dodatkowe opcje” NIE powinny zawierać /machine:X86

Mam taki klucz, wygenerowany przez dane wyjściowe CMake: CMake wygenerował projekt x86, a następnie dodałem platformę x64 poprzez Configuration ManagerVisual Studio 2010 - wszystko zostało stworzone dobrze dla nowej platformy, z wyjątkiem tego, że wiersz poleceń linkera został określony /machine:X86osobno.

Ten sam problem wystąpił w VS2008, gdy próbowałem dodać kompilację X64 do projektu przekonwertowanego z VS2003.

Patrzyłem na wszystko znalezione podczas wyszukiwania tego błędu w Google (maszyna docelowa, katalogi VC ++, DUMPBIN ....) i wszystko wyglądało OK.

W końcu stworzyłem nowy projekt testowy, wprowadziłem te same zmiany i wydawało się, że działa.

Różnice między plikami vcproj ujawniły problem ....

Mój przekonwertowany projekt miał / MACHINE: i386 ustawiony jako dodatkowy zestaw opcji w Linker-> Wiersz poleceń. Tak więc ustawiono dwie opcje / MACHINE (zarówno x64, jak i i386), a dodatkowa miała pierwszeństwo.

Usunięcie tego i ustawienie go poprawnie w obszarze Linker-> Zaawansowane-> Maszyna docelowa sprawiło, że problem zniknął.

Wszystkie ustawienia projektu wydawały się idealne, ale wciąż pojawia się błąd. Przejrzenie .vcxprojpliku i wyszukanie „x86” ujawniło problem:

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

Szybkie wyszukiwanie / zamiana wszystkich wystąpień (dziesięć indywidualnych ustawień plików) naprawiło problem.

Ponieważ problem wynika z różnicy w kompilacji i specyfikacji komputera docelowego (x86 i x64) Wykonaj następujące czynności:

1. Otwórz projekt C ++, który chcesz skonfigurować.
2. Wybierz przycisk Menedżer konfiguracji, aby otworzyć okno dialogowe Menedżer konfiguracji.
3. Z listy rozwijanej Aktywna platforma rozwiązań wybierz opcję otwarcia okna dialogowego Nowa platforma rozwiązań.
4. Z listy rozwijanej Typ lub wybierz nową platformę wybierz platformę 64-bitową.

To rozwiązało mój problem.

Prawdopodobnie masz jeden plik .OBJ lub .LIB, który jest przeznaczony dla x64 (jest to typ maszyny modułowej), podczas gdy łączysz się z x86 (to jest typ maszyny docelowej).

Użyj DUMPBIN / HEADERS na swoich plikach .OBJ i sprawdź wpis maszyny w bloku WARTOŚCI NAGŁÓWEK PLIKU.

W programie Visual Studio 2012 +/- strona właściwości „Właściwości konfiguracji” Linker. „Wiersz polecenia” zawiera pole oznaczone „Dodatkowe opcje”. Jeśli budujesz x64, upewnij się, że to pole nie zawiera / MACHINE: I386. Moje projekty tak zrobiły i wygenerowałem omawiany błąd.

Natknąłem się na ten problem podczas budowania QT. Instrukcje, które gdzieś przeczytałem sugerowały, że konfiguruję nmake za pomocą wiersza polecenia VS.

Wybrałem wiersz polecenia x64 i przeprowadziłem konfigurację bez większych problemów. Kiedy próbowałem nmake, dał ten błąd.

Myślę, że niektóre komponenty zostały wstępnie zbudowane dla wersji 32-bitowej. Błąd informował nawet, które moduły zostały zbudowane dla x86.

Użyłem domyślnego 32-bitowego wiersza polecenia VS i zadziałało.

W Visual Studio 2013

1) Sprawdź strony właściwości projektu / właściwości konfiguracji / konsolidatora / wszystkie opcje i popraw wszystkie brakujące skonfigurowane maszyny i katalogi.

2) Sprawdź strony właściwości projektu / właściwości konfiguracji / konsolidatora / danych wejściowych i popraw wszystkie brakujące skonfigurowane katalogi.

Zobacz przykład 1)

Plik vcxproj może zawierać „MACHINE: i386” Edytuj plik vcxproj za pomocą edytora. usunąć to !

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

Ustaw 64-bitową opcję kompilacji -m64 -cubin

Podpowiedź znajduje się w dzienniku kompilacji. Lubię to:

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

To "-machine 32"jest problem.

Najpierw ustaw opcję kompilacji 64-bitowej, następnie ponownie ustaw opcję kompilacji hybrydowej. Wtedy zobaczysz sukces.

Jeśli twoje rozwiązanie ma projekty lib, sprawdź właściwość Komputer docelowy w Właściwości-> Bibliotekarz-> Ogólne

Oprócz listy Jhonsona sprawdź także foldery biblioteki

W Visual Studio wybierz Narzędzia> Opcje z menu głównego. wybierz Projekty i rozwiązania> Katalogi VC ++. Wybierz x64 z menu rozwijanego Platforma.

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

Zdarzyło mi się to dzisiaj, ponieważ dodałem katalog biblioteki jeszcze w trybie x86 i przypadkowo usunąłem odziedziczone katalogi, zamiast tego zapisałem je na stałe. Następnie po przejściu na x64 moje katalogi VC ++ nadal czytają:

„...; $ (VC_LibraryPath_x86); $ (WindowsSDK_LibraryPath_x86);”

zamiast _x64.

Korzystałem z CMake, a następnie dodałem konfigurację Win32. Strona właściwości pokazała x86, ale tak naprawdę podczas otwierania pliku vcxproj w edytorze tekstów była to x64! Rozwiązało to ręczne przejście na x86.

Jest to bardzo frustrujący i irytujący problem, ale kiedy go zrozumiesz, jest dość prosty: masz jakiś element, który budujesz, budując jeden typ architektury (w twoim przypadku x64) pomimo faktu, że był on celem innego typu (powiedzmy x86 ).

Możesz przeanalizować źródło problemu, sprawdzając, który plik obj powoduje awarię i zacznij szukać tam problemu. Każdy obiekt będzie miał kod źródłowy analogowy: w cpp, c, asm itp. Mogą się tam znajdować specjalne zdarzenia kompilacji, które używają niewłaściwego narzędzia. Sprawdź to w arkuszach właściwości.

Najpierw zajrzałbym tam, zanim przejrzałem listę rzeczy do zrobienia w C Johnson.

Rozwiązałem ten problem, zmieniając Win32 na * 64 w Visual Studio 2013.

moduł typ maszyny to maszyna, na której kompilujesz, a typem maszyny docelowej jest architektura x86 lub x64, dla której budujesz pliki binarne.

Ten problem może również wystąpić, jeśli w projekcie skonfigurowano takie same katalogi pośrednie we Właściwościach projektu -> Właściwości konfiguracji -> Ogólne

Najpierw wypróbuj następujące rzeczy: 1. goto Configuration Manager i utwórz nowy x64, jeśli jeszcze go nie ma. 2. wybierz rozwiązanie x64. 3. przejdź do właściwości projektu, a następnie Linker-> Zaawansowane wybierz maszynę x64. 4. Teraz odbuduj rozwiązanie.

Jeśli nadal pojawia się ten sam błąd. wypróbuj czyste rozwiązanie, a następnie przebuduj ponownie i otwórz studio wizualne, a otrzymasz listę ostatnio otwartych projektów, kliknij projekt prawym przyciskiem myszy i usuń go. Teraz przejdź do rozwiązania i ponownie otwórz rozwiązanie.

zdarza mi się to, gdy przekonwertuję moje rozwiązanie VS2008 na VS2010 i zmieniam konfigurację win32 na X64, w moim starym rozwiązaniu mam plik mfcs90d.lib (Konfiguracja-> Linker-> Wejście-> Dodatkowe zależności), ponieważ korzystam z VS010, właśnie sprawdziłem w folderze VS2010, gdzie jest to mfcs100d.lib, więc zmieniłem mfcs90d.lib na mfcs100d.lib w (Konfiguracja-> Linker-> Wejście-> Dodatkowe zależności) działało dobrze.

Dla tych, którzy korzystają z QT Creator, problem jest taki sam (zgodnie z opisem @ c-johnson). Upewnij się, że ustawienia kompilatora dla MSVC w twoim zestawie są ustawione na x86, jak pokazano poniżej.

dla niektórych korzystających z wiersza polecenia (dos dos) może to być pomocne:

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.

Również jeśli to zrobisz:

CL "% 1% 2% 3" / EHsc / link user32.lib Gdi32.lib Winmm.lib comctl32.lib * .obj / PODSYSTEM: CONSOLE / MACHINE: x86

trzeba del * .obj przed ; uniknąć pomylonego linkera z 64-bitowymi i 32-bitowymi obiektami pozostałymi po wcześniejszych kompilacjach?

Wiele dobrych sugestii powyżej.

Również jeśli próbujesz zbudować w x86 Win32:

Upewnij się, że wszystkie biblioteki, do których linkujesz w Program Files (x86), są w rzeczywistości bibliotekami x86, ponieważ niekoniecznie są ...

Na przykład plik lib, do którego podłączyłem w C: \ Program Files (x86) \ Microsoft Visual Studio \ 2019 \ Professional \ SDK, zgłosił ten błąd, w końcu znalazłem jego wersję x86 w C: \ Program Files (x86) \ Windows Zestawy \ 10 \ Lib \ 10.0.18362.0 \ um \ x86 i wszystko działało dobrze.

jaki jest system operacyjny jeśli jest to Windows x64, musisz upewnić się, że CUDA x64 został zainstalowany i że VS2008 powinien skompilować projekt w trybie x64 ...

CUDA zainstaluje x64 LUB x86 tylko w systemie Windows