Stworzyłem nowy projekt C ++ w Visual Studio 2008. Żaden kod nie został jeszcze napisany; Zmieniono tylko ustawienia projektu.
Kiedy kompiluję projekt, otrzymuję następujący błąd krytyczny:
błąd krytyczny LNK1104: nie można otworzyć pliku „C: \ Program.obj”
Odpowiedzi:
Ten konkretny problem jest spowodowany określeniem zależności od pliku lib, który zawiera spacje w ścieżce. Ścieżka musi być ujęta w cudzysłów, aby projekt został poprawnie skompilowany.
Na karcie Właściwości konfiguracji -> Konsolidator -> Dane wejściowe właściwości projektu znajduje się właściwość Dodatkowe zależności . Ten problem został rozwiązany przez zmianę tej właściwości z:
C: \ Program Files \ sofware sdk \ lib \ library.lib
Do:
„C: \ Program Files \ sofware sdk \ lib \ library.lib”
Gdzie dodałem cytaty.
"C:\Program Files\sofware sdk\lib\library.lib". Brak znaku ;spowoduje również niepoprawną kompilację projektu.
Może się to zdarzyć, jeśli plik również nadal działa.
: -1: błąd: LNK1104: nie można otworzyć pliku „debug \ ****. Exe”
Problem zniknął po zamknięciu i ponownym otwarciu programu Visual Studio. Nie wiem, dlaczego wystąpił problem, ale może warto spróbować.
To było w VS 2013 Ultimate, Windows 8.1.
Sprawdź także, czy nie masz włączonej tej opcji: Właściwości konfiguracji -> C / C ++ -> Preprocessor -> Preprocess to a File .
Moim problemem było brakujące .librozszerzenie, właśnie łączyłem się z nim mylibi VS zdecydował się poszukać mylib.obj.
Rozwiązanie 1 (w moim przypadku): uruchom ponownie proces Eksploratora Windows (tak, menedżer plików systemu Windows).
Rozwiązanie 2:
Przypuszczam, że czasami system plików lub ktokolwiek go kontroluje, gubi się ze swoimi uprawnieniami. Przed ponownym uruchomieniem sesji systemu Windows próbowałem zabić msbuild32.exeprocesy zombie , zrestartować Visual Studio, sprawdzić, czy żaden z nich nie pokazuje nawet pliku powodującego problem. Brak problemów z konfiguracją kompilacji. To się zdarza od czasu do czasu. Niektóre wewnętrzne rzeczy w systemie Windows nie naprawiają się, wymagają ponownego uruchomienia.
Miałem ten sam błąd, tylko z pakietem Nuget, który zainstalowałem (taki, który nie jest tylko nagłówkiem), a następnie próbowałem odinstalować.
To, co było dla mnie nie tak, to fakt, że nadal dołączałem nagłówek pakietu, który właśnie odinstalowałem, w jednym z moich plików .cpp (całkiem głupie, tak).
Usunąłem nawet link do dodatkowych katalogów biblioteki Project -> Properties -> Linker -> General, ale oczywiście bezskutecznie, ponieważ wciąż próbowałem odwołać się do nieistniejącego nagłówka.
Zdecydowanie mylący komunikat o błędzie w tym przypadku, ponieważ nazwa nagłówka była, <boost/filesystem.hpp>ale błąd dał mi "cannot open file 'llibboost_filesystem-vc140-mt-gd-1_59.lib'"i żadnych numerów linii ani nic.
Miałem ten sam problem, ale rozwiązania dla mojego przypadku nie ma w odpowiedziach. Mój program antywirusowy (AVG) określił plik MyProg.exejako wirusa i umieścił go w „magazynie wirusów”. Musisz sprawdzić ten magazyn i jeśli plik tam jest - po prostu go przywróć. Pomogło mi.
Napotykam ten sam problem z linkerem narzekającym na brak głównego pliku wykonywalnego. Stało się to podczas przenoszenia naszego rozwiązania do nowego programu Visual Studio 2013 . Rozwiązanie to zróżnicowana mieszanka zarządzanych i niezarządzanych projektów / kodu. Problem (i rozwiązanie) zakończył się brakiem pliku app.config w folderze rozwiązania. Zajęło mi to dzień, aby to rozgryźć :( ponieważ dziennik wyjściowy nie był zbyt pomocny.
Sprawdziłem wszystkie moje ustawienia zgodnie z tą listą: http://msdn.microsoft.com/en-us/library/ts7eyw4s.aspx#feedback . Jest to dla mnie pomocne i w mojej sytuacji dowiaduję się, że właściwości Link Dependency projektów mają podwójne cudzysłowy, których nie powinno tam być.
Odpowiadam, ponieważ nie widzę tego konkretnego rozwiązania na liście nikogo innego.
Najwyraźniej mój program antywirusowy (Ad-Aware) oznaczał bibliotekę DLL, od której zależy jeden z moich projektów, i usuwał ją. Nawet po wykluczeniu katalogu, w którym znajduje się biblioteka DLL, to samo zachowanie trwało do momentu ponownego uruchomienia komputera.
W moim przypadku zastąpiłem pliki bibliotek matematycznych z poprzedniego kursu Game Engine Graphics na GLM. Problem polegał na tym, że nie dodałem ich do projektu w programie Visual Studio Solution Explorer (mimo że znajdowały się w repozytorium projektu).
Miałem ten problem w połączeniu z błędem LNK2038, śledziłem ten post aby posegregować biblioteki DLL RELEASE i DEBUG. W trakcie tego procesu wyczyściłem cały folder, w którym znajdowały się te zależności.
Na szczęście miałem kopię zapasową wszystkich tych plików i otrzymałem plik, dla którego ten błąd był wrzucany z powrotem do folderu DEBUG, aby rozwiązać problem. Kod błędu był w jakiś sposób mylący, ponieważ musiałem spędzić dużo czasu, aby ponownie dojść do tej wskazówki z jednej z odpowiedzi z tego postu.
Mam nadzieję, że ta odpowiedź pomoże komuś w potrzebie.
Rozwiązałem go przez dodanie o istniejący projekt do mojego rozwiązania , które zapomniał dodać w po raz pierwszy.
Miałem ten sam błąd:
fatal error LNK1104: cannot open file 'GTest.lib;'Było to spowodowane ;końcem. Jeśli masz wiele bibliotek, należy je oddzielić pustą spacją (spacją), bez przecinków ani średników!
Więc nie używaj ;ani niczego innego, wymieniając biblioteki wProject properties >> Configuration Properties >> Linker >> Input
Wypróbowałem powyższe rozwiązanie, ale nie zadziałało. Więc zmieniam nazwę exe i odbudowuję rozwiązanie. Mi to pasuje.
Miałem dokładnie ten błąd podczas tworzenia biblioteki DLL VC ++ w programie Visual Studio 2019:
LNK1104: nie można otworzyć pliku „C: \ Program.obj”
Okazało się, że w obszarze Właściwości projektu> Konsolidator> Dane wejściowe> Plik definicji modułu określiłem plik def, który miał niedopasowany podwójny cudzysłów na końcu nazwy pliku. Usunięcie niedopasowanego podwójnego cudzysłowu rozwiązało problem.
Ten sam problem napotkałem w „Visual Studio 2013”.
LNK1104: cannot open file 'debug\****.exeProblem rozwiązał się po zamknięciu i ponownym uruchomieniu programu Visual Studio.
Miałem ten sam problem, właśnie skopiowałem kod do nowego projektu i rozpocząłem kompilację. Zaczął się pojawiać inny błąd. błąd C4996: „fopen”: ta funkcja lub zmienna może być niebezpieczna. Zamiast tego rozważ użycie fopen_s
Aby ponownie rozwiązać ten problem, dodałem moją jedyną właściwość w projekcie projektu, jak poniżej. Projekt -> Właściwości -> Właściwość konfiguracji -> c / c ++. W tej kategorii znajduje się nazwa pola Definicje preprocesora Dodałem _CRT_SECURE_NO_WARNINGS to, aby rozwiązać problem Mam nadzieję, że pomoże ...
Dziękuję Ci