visual-c++ linker - Warum tritt der schwerwiegende Fehler "LNK1104:Datei kann nicht geöffnet werden" C:\ Program.obj "" auf, wenn ich ein C++-Projekt in Visual Studio kompiliere?




einstellungen 2017 (17)

Ich habe ein neues C ++ - Projekt in Visual Studio 2008 erstellt. Es wurde noch kein Code geschrieben. Nur Projekteinstellungen wurden geändert.

Wenn ich das Projekt kompiliere, erhalte ich den folgenden schwerwiegenden Fehler:

Schwerwiegender Fehler LNK1104: Datei 'C: \ Program.obj' kann nicht geöffnet werden


Answers

Ich überprüfte alle meine Einstellungen gemäß dieser Liste: http://msdn.microsoft.com/en-us/library/ts7eyw4s.aspx#feedback . Es ist hilfreich für mich und für meine Situation finde ich heraus, dass Linkabhängigkeit von Projekteigenschaften doppelte Anführungszeichen hat, die nicht dort sein sollten.


Dies kann passieren, wenn die Datei noch läuft.

: -1: Fehler: LNK1104: kann die Datei 'debug \ ****. Exe' nicht öffnen


Ich stoße auf das gleiche Problem mit Linker, der sich über die fehlende Hauptdatei kläglich beschwert. Dies geschah während unseres Lösungs-Ports für das neue Visual Studio 2013 . Die Lösung ist eine vielfältige Mischung aus verwalteten und nicht verwalteten Projekten / Code. Das Problem (und die Fehlerbehebung ) endete damit, dass die Datei app.config im Lösungsordner fehlte. Es dauerte einen Tag, um herauszufinden, wie: out, (wie Ausgabe-Protokoll war nicht sehr hilfreich.


Lösung 1 (für meinen Fall): Windows Explorer-Prozess neu starten (ja, der Windows-Dateimanager).

Lösung 2:

  1. Schließen Sie Visual Studio. Windows Abmelden
  2. Anmelden, Visual Studio erneut öffnen
  3. Bauen Sie wie gewohnt auf. Es baut jetzt auf und kann auf die problematische Datei zugreifen.

Ich vermute manchmal, dass das Dateisystem oder wer es kontrolliert, mit seinen Berechtigungen verloren geht. Vor dem Neustart der Windows-Sitzung, versucht, Zombie msbuild32.exe Prozesse zu töten, Visual Studio neu starten, überprüfen Sie keine sogar die Problemdatei auf. Keine Buildkonfigurationsprobleme. Es passiert ab und zu. Einige interne Dinge in Windows repariert nicht, benötigt einen Neustart.


In meinem Fall hatte ich Mathe-Bibliotheksdateien von einem früheren Game Engine Graphics-Kurs mit GLM ersetzt. Das Problem war, dass ich sie nicht zum Projekt innerhalb des Projektmappen-Explorers von Visual Studio hinzufügte (obwohl sie sich im Projekt-Repository befanden).


Ich hatte den gleichen Fehler, nur mit einem Nuget-Paket, das ich installiert hatte (eine, die nicht nur Header ist) und versuchte dann zu deinstallieren.
Was für mich falsch war, war, dass ich immer noch eine Kopfzeile für das Paket, das ich gerade in einer meiner .cpp-Dateien deinstalliert hatte (ziemlich dumm, ja).
Ich habe sogar den zusätzlichen Bibliotheksverzeichnis-Link dazu in Project -> Properties -> Linker -> General , aber natürlich ohne Erfolg, da ich immer noch versuchte, auf den nicht existierenden Header zu verweisen.

Definitiv eine verwirrende Fehlermeldung in diesem Fall, da der Header-Name <boost/filesystem.hpp> aber der Fehler gab mir "cannot open file 'llibboost_filesystem-vc140-mt-gd-1_59.lib'" und keine Zeilennummern oder irgendetwas .


Mein Problem war eine fehlende .lib Erweiterung, ich habe gerade eine Verbindung mit mylib und VS hat sich entschieden, nach mylib.obj zu suchen.


Ich hatte das gleiche Problem, ich habe gerade den Code in ein neues Projekt kopiert und den Build gestartet. Irgendein anderer Fehler fing an zu kommen. Fehler C4996: 'fopen': Diese Funktion oder Variable ist möglicherweise nicht sicher. Erwäge stattdessen, fopen_s zu verwenden

Um dieses Problem erneut zu lösen, habe ich meine eine Eigenschaft im Projekt-Projekt wie folgt hinzugefügt. Projekt -> Eigenschaften -> Konfigurationseigenschaft -> c / c ++. In dieser Kategorie gibt es Feldname Preprozessor-Definitionen Ich habe _CRT_SECURE_NO_WARNINGS hinzugefügt, um das Problem zu lösen. Hoffe, es wird helfen ...

Danke


Ich hatte dieses Problem in Verbindung mit dem LNK2038-Fehler, gefolgt von diesem post um die RELEASE- und die DEBUG-DLLs zu trennen. In diesem Prozess hatte ich den ganzen Ordner aufgeräumt, in dem diese Abhängigkeiten lagen.

Zum Glück hatte ich eine Sicherungskopie aller dieser Dateien und bekam die Datei, für die dieser Fehler in den DEBUG-Ordner zurückgeworfen wurde, um das Problem zu lösen. Der Fehlercode war in gewisser Weise irreführend, da ich viel Zeit investieren musste, um zu diesem Tipp von einer der Antworten von diesem Beitrag wieder zu kommen.

Hoffe diese Antwort, hilft jemandem in Not.


Ich antworte, weil ich nicht sehe, dass diese spezielle Lösung von jemand anderem aufgeführt wird.

Anscheinend hat mein Antivirenprogramm (Ad-Aware) eine DLL markiert, von der eines meiner Projekte abhängt, und es gelöscht. Auch nach dem Ausschließen des Verzeichnisses, in dem sich die DLL befindet, wurde das gleiche Verhalten fortgesetzt, bis ich meinen Computer neu startete.


Dieses spezielle Problem wird dadurch verursacht, dass eine Abhängigkeit zu einer lib-Datei angegeben wird, die Leerzeichen in ihrem Pfad enthält. Der Pfad muss von Anführungszeichen umgeben sein, damit das Projekt korrekt kompiliert werden kann.

Auf der Registerkarte Konfigurationseigenschaften -> Linker -> Eingabe der Projekteigenschaften gibt es die Eigenschaft Zusätzliche Abhängigkeiten . Dieses Problem wurde behoben, indem diese Eigenschaft geändert wurde von:

C: \ Programme \ sofware sdk \ lib \ library.lib

Zu:

"C: \ Programme \ sofware sdk \ lib \ library.lib"

Wo ich die Zitate hinzugefügt habe.


Ich hatte den gleichen Fehler:

fatal error LNK1104: cannot open file 'GTest.lib;'

Dies wurde verursacht durch die ; Am Ende. Wenn Sie mehrere Bibliotheken haben, sollten sie durch Leerzeichen (Leertaste), kein Komma oder Semikolon getrennt sein!

Also nicht benutzen ; oder irgendetwas anderes beim Auflisten von Bibliotheken in Projekteigenschaften >> Konfigurationseigenschaften >> Linker >> Eingabe


Für ein Assembly-Projekt (ProjectName -> Build-Abhängigkeiten -> Build-Anpassungen -> masm (selected)) verursachte die Einstellung " Generate Preprocessed Source Listing" auf True das Problem auch für mich, das Löschen der Einstellung behob es. VS2013 hier.


Ich hatte das gleiche Problem, aber die Lösung für meinen Fall ist nicht in den Antworten aufgeführt. Mein Antivirus-Programm (AVG) hat die Datei MyProg.exe als Virus ermittelt und in den 'Virusspeicher' gesteckt. Sie müssen dieses Lagerhaus überprüfen und wenn Datei dort ist - dann stellen Sie es einfach wieder her. Es hat mir geholfen.


Nach dem Schließen und erneuten Öffnen von Visual Studio ging das Problem für mich weg. Nicht sicher, warum das Problem passiert ist, aber das könnte einen Versuch wert sein.

Dies war auf VS 2013 Ultimate, Windows 8.1.


In meinem Fall handelte es sich um eine fehlgeleitete Referenz. Das Projekt referenzierte die Ausgabe eines anderen Projekts, aber das letztere gab die Datei nicht aus, in der der vorherige gesucht hatte.








visual-c++ linker