Visual Studio: LINK: Schwerwiegender Fehler LNK1181: Eingabedatei kann nicht geöffnet werden

Ich habe seit einiger Zeit einen seltsamen Fehler in Visual Studio 2010 festgestellt.

Ich habe eine Lösung, die aus einem Projekt besteht, das zu einer statischen Bibliothek kompiliert wird, und einem anderen Projekt, das wirklich einfach ist, aber von dieser Bibliothek abhängt.

Manchmal, in den letzten Tagen sehr häufig, erhalte ich nach dem Neuerstellen der Lösung oder dem Kompilieren mit 1-3 geänderten Quelldateien die folgende Fehlermeldung:

2>LINK : fatal error LNK1181: cannot open input file 'thelibrary.lib'
========== Rebuild All: 1 succeeded, 1 failed, 0 skipped ==========

Wo das Kompilieren thelibrary.libohne Fehler oder Warnungen erfolgreich war.

Ich habe versucht, die Lösung zu reinigen, aber das funktioniert nicht immer.

• Was ist hier falsch?

Fügen Sie in Linker, allgemeinen, zusätzlichen Bibliotheksverzeichnissen, das Verzeichnis der DLL oder .libs hinzu, die Sie in Linker, Input, enthalten haben. Es funktioniert nicht, wenn Sie dies in VC ++ - Verzeichnisse, Bibliotheksverzeichnisse einfügen.

Gehe zu:

Project properties -> Linker -> General -> Link Library Dependencies set No.

Ich kann hier nur 1 Dinge sehen: Sie haben in Ihrem Projekt die Abhängigkeiten zu thelibrary.lib nicht richtig festgelegt, was bedeutet, dass thelibrary.lib in der falschen Reihenfolge erstellt wird (oder zur gleichen Zeit, wenn Sie mehr als 1 CPU-Build-Konfiguration haben). was auch die Zufälligkeit des Fehlers erklären kann). (Sie können die Projektabhängigkeiten ändern unter: Menü-> Projekt-> Projektabhängigkeiten)

Ich habe vor kurzem den gleichen Fehler getroffen. Einige Grabungen brachten dies hervor: http://support.microsoft.com/kb/815645

Grundsätzlich ist das schlecht, wenn Sie Leerzeichen im Pfad der .lib haben. Ich weiß nicht, ob das für Sie passiert, scheint aber vernünftigerweise möglich zu sein.

Das Update lautet entweder 1) Setzen Sie die lib-Referenz in "Anführungszeichen" oder 2) fügen Sie den Pfad der lib zu Ihren Bibliotheksverzeichnissen hinzu (Konfigurationseigenschaften >> VC ++ - Verzeichnisse).

Ich hatte das gleiche Problem sowohl in VS 2010 als auch in VS 2012. Auf meinem System wurde die erste statische Bibliothek erstellt und dann sofort gelöscht, als das Hauptprojekt mit der Erstellung begann.

Das Problem ist der gemeinsame Zwischenordner für mehrere Projekte. Weisen Sie einfach jedem Projekt einen eigenen Zwischenordner zu.

Lesen Sie mehr dazu hier

Ich habe es mit folgendem gelöst:

Gehen Sie zu Ansicht-> Eigenschaftenseiten -> Konfigurationseigenschaften -> Linker -> Eingabe

Fügen Sie unter zusätzlichen Abhängigkeiten die Datei thelibrary.lib hinzu. Verwenden Sie keine Zitate.

Ich hatte ein ähnliches Problem, da ich LINK1181Fehler in der .OBJDatei bekam, die Teil des Projekts selbst war (und es gab nur 2 .cxx-Dateien im gesamten Projekt).

Anfangs hatte ich das Projekt so eingerichtet, dass es .EXEin Visual Studio generiert wird , und dann habe Property Pages -> Configuration Properties -> General -> Project Defaults -> Configuration Typeich in .EXE in .DLL geändert. Ich hatte den Verdacht, dass Visual Studio 2008 irgendwie verwirrt war, und habe die gesamte Lösung von Anfang an im DLL-Modus von Grund auf neu erstellt. Das Problem ging danach weg. Ich stelle mir vor, wenn Sie sich manuell durch die .vcproj- und andere verwandte Dateien wühlen, können Sie herausfinden, wie Sie Probleme beheben können, ohne von vorne zu beginnen (aber mein Programm bestand aus zwei .cpp-Dateien, sodass es einfacher war, von vorne zu beginnen).

Ich stolpere über das gleiche Thema. Für mich scheint es daran zu liegen, dass zwei Projekte mit demselben Namen voneinander abhängig sind.

Zum Beispiel habe ich ein Projekt namens Foo, das Foo.lib produziert. Ich habe dann ein anderes Projekt, das auch Foo heißt und Foo.exe und Links in Foo.lib produziert.

Ich habe die Dateiaktivität mit Process Monitor beobachtet. Was zu passieren scheint, ist, dass Foo (lib) zuerst erstellt wird - was richtig ist, weil Foo (exe) als abhängig von Foo (lib) markiert ist. Dies ist alles in Ordnung und wird erfolgreich erstellt und im Ausgabeverzeichnis abgelegt - $ (OutDir) $ (TargetName) $ (TargetExt). Dann wird Foo (exe) ausgelöst, um neu zu erstellen. Nun, ein Umbau ist ein sauberer, gefolgt von einem Build. Es scheint, als würde die 'saubere' Phase von Foo.exe Foo.lib aus dem Ausgabeverzeichnis löschen. Dies erklärt auch, warum ein nachfolgender 'Build' funktioniert - das gibt keine Ausgabedateien aus.

Ein Fehler in VS, denke ich.

Leider habe ich keine Lösung für das Problem, da es sich um eine Neuerstellung handelt. Eine Problemumgehung besteht darin, Clean und anschließend Build manuell auszugeben.

Ich weiß nicht warum, aber ich ändere den Link Linker-> Eingabe-> Zusätzliche Abhängigkeiten von "dxguid.lib" in "C: \ Programme (x86) \ Microsoft DirectX SDK (Juni 2010) \ Lib \ x86 \ dxguid. lib "(in meinem Fall) war das einzige, was funktionierte.

Für mich war das Problem ein falsches includeVerzeichnis. Ich habe keine Ahnung, warum dies den Fehler mit der scheinbar fehlenden Bibliothek verursacht hat, da das Include-Verzeichnis nur die Header-Dateien enthält. Und für das Bibliotheksverzeichnis wurde der richtige Pfad festgelegt.

Möglicherweise haben Sie ein Hardwareproblem.

Ich hatte das gleiche Problem auf meinem alten System (AMD 1800 MHz CPU, 1 GB RAM, Windows 7 Ultimate), bis ich den 2x 512 MB RAM in 2x 1 GB RAM änderte . Habe seitdem keine Probleme mehr gehabt. Auch andere (kleinere) Probleme verschwanden. Vermutlich mochten sich diese beiden 512-MB-Module nicht so sehr, weil 2x 512 MB + 1 GB oder 1x 512 MB + 2x 1 GB auch nicht richtig funktionierten.

Sie können das Problem mit den Leerzeichen im Pfad auch beheben, indem Sie den Bibliothekspfad im DOS-Format "8.3" angeben.

Um das 8.3-Formular zu erhalten, gehen Sie wie folgt vor (in der Befehlszeile):

DIR /AD /X

rekursiv durch jede Ebene der Verzeichnisse.

Ich hatte das gleiche Problem. Es wurde gelöst, indem ein Makro definiert wurde OBJECTS, das alle Linkerobjekte enthält, z.

OBJECTS = target.exe kernel32.lib mylib.lib (etc)

Und dann spezifizieren $(OBJECTS) in der Befehlszeile des Linkers angeben.

Ich benutze allerdings kein Visual Studio , nur nmake und eine .MAK-Datei

Ich hatte den gleichen Fehler beim Ausführen von lib.exe von cmd unter Windows mit einer langen Argumentliste. Anscheinend hat cmd.exe eine maximale Zeilenlänge von ca. 8 KB, was dazu führte, dass die Dateinamen am Ende dieses Schwellenwerts geändert wurden, was zu einem fehlerhaften Dateinamenfehler führte. Meine Lösung bestand darin, die Linie zu kürzen. Ich habe alle Pfade aus Dateinamen entfernt und mit der Option / LIBPATH einen einzelnen Pfad hinzugefügt. zum Beispiel:

/LIBPATH:absolute_path /OUT:outfilename filename1.obj filename2.obj ... filenameN.obj

Ich habe eine andere Lösung dafür gefunden ...

Eigentlich habe ich das Komma-Trennzeichen zwischen zwei Bibliothekspfaden verpasst. Nach dem Hinzufügen von Common hat es bei mir funktioniert.

Gehe zu: Project properties -> Linker -> General -> Link Library Dependencies Stellen Sie unter diesem Pfad sicher, dass der Pfad der Bibliothek korrekt ist.

Vorheriger Code ( mit Fehler - weil ich vergessen habe, zwei lib-Pfade durch Komma zu trennen):

<Link><AdditionalLibraryDirectories>..\..\Build\lib\$(Configuration)**..\..\Build\Release;**%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>

Code nach dem Fix (Nur Bibliotheken mit Komma trennen):

<Link><AdditionalLibraryDirectories>..\..\Build\lib\$(Configuration)**;..\..\Build\Release;**%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>

Hoffe das wird dir helfen.

In meinem Fall hatte ich die Bibliothek mit dem NuGet-Paket (cpprestsdk) installiert und die Bibliothek fälschlicherweise zu den zusätzlichen Abhängigkeiten in den Linker-Einstellungen hinzugefügt. Es stellt sich heraus, dass das Paket alles für Sie erledigt.

Der Linker hat dann versucht, die Bibliothek im Bibliothekspfad zu finden und konnte sie natürlich nicht finden.

Nach dem Entfernen der Bibliothek aus den zusätzlichen Abhängigkeiten wurde alles kompiliert und verknüpft.

Ich habe ein binVerzeichnis auf der Ebene project_dir erstellt und dann ein release/debugVerzeichnis im binOrdner erstellt, wodurch das Problem für mich gelöst wurde.