wake-up-neo.net

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

In Visual Studio 2010 ist seit einiger Zeit ein seltsamer Fehler aufgetreten.

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 den folgenden Fehler:

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

Wo kompiliert thelibrary.lib war ein Erfolg ohne Fehler oder Warnungen.

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

  • Was ist hier falsch?
72
Komn

Fügen Sie in Linker, allgemeine, zusätzliche Bibliotheksverzeichnisse das Verzeichnis zu den DLLs oder LIBs hinzu, die Sie in Linker, Eingabe, enthalten haben. Es funktioniert nicht, wenn Sie dies in VC++ - Verzeichnissen, Bibliotheksverzeichnissen ablegen.

40
Chris Thorne

Gehe zu:

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

Ich kann hier nur 1 Dinge beobachten: Sie haben die Abhängigkeiten zur Bibliothek.lib in Ihrem Projekt nicht richtig eingestellt, was bedeutet, dass die Bibliothek.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 unter: Menü-> Projekt-> Projektabhängigkeiten ändern.)

9
Sasha

Ich bin kürzlich auf den gleichen Fehler gestoßen. Einige Grabungen brachten dies zum Vorschein: http://support.Microsoft.com/kb/815645

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

Das Update besteht entweder darin, 1) die lib-Referenz in "Anführungszeichen" zu setzen oder 2) den Pfad der lib zu Ihren Bibliotheksverzeichnissen hinzuzufügen (Konfigurationseigenschaften >> VC++ - Verzeichnisse).

7
Clippy

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

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

Lesen Sie mehr dazu hier

4
alexkr

Ich habe es mit folgendem gelöst:

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

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

2
user2049230

Ich hatte insofern ein ähnliches Problem, als ich LINK1181 Fehler auf dem .OBJ-Datei, die Teil des Projekts selbst war (und das gesamte Projekt enthielt nur 2 .cxx-Dateien).

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

2
user1726157

Ich weiß nicht warum, aber ändere den Linker-> Input-> Additional Dependencies-Verweis von "dxguid.lib" auf "C:\Programme (x86)\Microsoft DirectX SDK (Juni 2010)\Lib\x86\dxguid". lib "(in meinem Fall) war das einzige, was funktionierte.

1
Vic

Ich stolpere über das gleiche Thema. Für mich scheint es, dass es zwei Projekte mit dem gleichen Namen gibt, eines davon hängt vom anderen ab.

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 erzeugt.

Ich habe die Dateiaktivität mit Process Monitor beobachtet. Was zu passieren scheint, ist, dass zuerst Foo (lib) erstellt wird - was richtig ist, da 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 Rebuild ist ein Clean gefolgt von einem Build. Es sieht so aus, als ob die 'saubere' Phase von Foo.exe Foo.lib aus dem Ausgabeverzeichnis löscht. Dies erklärt auch, warum ein nachfolgender "Build" funktioniert - der Ausgabedateien nicht löscht.

Ein Bug in VS, denke ich.

Leider habe ich keine Lösung für das Problem, da es sich um einen Neuaufbau handelt. Eine Problemumgehung besteht darin, Clean und dann Build manuell auszustellen.

1
Nick

Für mich war das Problem ein falsches include Verzeichnis. Ich habe keine Ahnung, warum dies den Fehler mit der scheinbar fehlenden Bibliothek verursacht, da das Include-Verzeichnis nur die Header-Dateien enthält. Und das Bibliotheksverzeichnis hatte den richtigen Pfad eingestellt.

1
mgttlinger

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 Zeichen, was dazu führte, dass die Dateinamen am Ende dieses Schwellenwerts geändert wurden, was zu einem falschen Dateinamenfehler führte. Meine Lösung bestand darin, die Leitung zu kürzen. Ich habe alle Pfade aus den Dateinamen entfernt und einen einzelnen Pfad mit der Option/LIBPATH hinzugefügt. beispielsweise:

/LIBPATH:absolute_path /OUT:outfilename filename1.obj filename2.obj ... filenameN.obj
0
Haim Itzhayek

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 das 2x 512 MB RAM zu - änderte 2x 1GB RAM. Hatte seitdem keine Probleme mehr. Auch andere (kleinere) Probleme sind verschwunden. Vermutlich haben sich die beiden 512 MB-Module nicht so gut gefallen, weil 2x 512 MB + 1GB) oder 1x 512 MB + 2x 1 GB hat auch nicht richtig funktioniert.

0
engf-010

In meinem Fall habe ich die Bibliothek mit dem NuGet-Paket (cpprestsdk) installiert UND die lib fälschlicherweise zu den Additional Dependancies in den Linker-Einstellungen hinzugefügt. Es stellt sich heraus, das Paket erledigt alles für Sie.

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 Additional Dependencies wird alles fein kompiliert und verlinkt.

0
Bojan Hrnkas

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

Eigentlich habe ich das Komma-Trennzeichen zwischen zwei Bibliothekspfaden verpasst. Nachdem ich common hinzugefügt hatte, funktionierte es für mich.

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

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

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

Code nach Fix (Bibliotheken nur durch Komma trennen):

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

Hoffe das wird dir helfen.

0
Shubham

Ich hatte das gleiche problem Das Problem wurde gelöst, indem ein Makro OBJECTS definiert wurde, das alle Linker-Objekte enthält, z.

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

Geben Sie dann $(OBJECTS) in der Befehlszeile des Linkers an.

Ich benutze aber nicht Visual Studio, sondern nur nmake und eine .MAK-Datei

0

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.

0
Pierre