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:
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ą.
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.
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.
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 Manager
Visual Studio 2010 - wszystko zostało stworzone dobrze dla nowej platformy, z wyjątkiem tego, że wiersz poleceń linkera został określony/machine:X86
osobno.źródło
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ął.
źródło
Wszystkie ustawienia projektu wydawały się idealne, ale wciąż pojawia się błąd. Przejrzenie
.vcxproj
pliku i wyszukanie „x86” ujawniło problem:Szybkie wyszukiwanie / zamiana wszystkich wystąpień (dziesięć indywidualnych ustawień plików) naprawiło problem.
źródło
Ponieważ problem wynika z różnicy w kompilacji i specyfikacji komputera docelowego (x86 i x64) Wykonaj następujące czynności:
To rozwiązało mój problem.
źródło
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.
źródło
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.
źródło
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.
źródł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)
źródło
Plik vcxproj może zawierać „MACHINE: i386” Edytuj plik vcxproj za pomocą edytora. usunąć to !
źródło
Ustaw 64-bitową opcję kompilacji
-m64 -cubin
Podpowiedź znajduje się w dzienniku kompilacji. Lubię to:
To
"-machine 32"
jest problem.Najpierw ustaw opcję kompilacji 64-bitowej, następnie ponownie ustaw opcję kompilacji hybrydowej. Wtedy zobaczysz sukces.
źródło
Jeśli twoje rozwiązanie ma projekty lib, sprawdź właściwość Komputer docelowy w Właściwości-> Bibliotekarz-> Ogólne
źródło
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.
źródło
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.
źródło
$(VC_LibraryPath_x64);$(WindowsSDK_LibraryPath_x64);$(NETFXKitsDir)Lib\um\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.
źródło
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.
źródło
Rozwiązałem ten problem, zmieniając Win32 na * 64 w Visual Studio 2013.
źródło
moduł typ maszyny to maszyna, na której kompilujesz, a typem maszyny docelowej jest architektura x86 lub x64, dla której budujesz pliki binarne.
źródło
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
źródło
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.
źródło
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.
źródło
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.
źródło
dla niektórych korzystających z wiersza polecenia (dos dos) może to być pomocne:
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?
źródło
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.
źródło
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
źródło