Visual Studio: LINK: erreur irrécupérable LNK1181: impossible d'ouvrir le fichier d'entrée
Je rencontre un bogue étrange dans Visual Studio 2010 depuis un certain temps maintenant.
J'ai une solution composée d'un projet qui compile dans une bibliothèque statique, et un autre projet qui est très simple mais qui dépend de cette bibliothèque.
Parfois, dans les derniers jours, extrêmement fréquente, après avoir reconstruit la solution ou simplement l'avoir compilée avec 1 à 3 fichiers sources modifiés, j'obtiens l'erreur suivante:
2>LINK : fatal error LNK1181: cannot open input file 'thelibrary.lib'
========== Rebuild All: 1 succeeded, 1 failed, 0 skipped ==========
Où compiler thelibrary.lib a été un succès sans erreurs ni avertissements.
J'ai essayé de nettoyer la solution, mais cela ne fonctionne pas toujours.
- Qu'est-ce qui ne va pas ici?
Dans l'éditeur de liens, général, des répertoires de bibliothèque supplémentaires, ajoutez le répertoire aux fichiers .dll ou .libs que vous avez inclus dans l'éditeur de liens, entrée. Cela ne fonctionne pas si vous mettez cela dans les répertoires VC++, les répertoires de bibliothèque.
Aller à:
Project properties -> Linker -> General -> Link Library Dependencies set No.
Je ne vois qu'une chose qui se passe ici: vous n'avez pas correctement défini les dépendances à thelibrary.lib dans votre projet, ce qui signifie que thelibrary.lib est construit dans le mauvais ordre (ou dans le même temps si vous avez plus d'une configuration de construction de CPU, qui peut aussi expliquer le caractère aléatoire de l’erreur). (Vous pouvez modifier les dépendances du projet dans: Menu-> Projet-> Dépendances du projet)
J'ai récemment frappé la même erreur. Des travaux de fouille ont amené ceci: http://support.Microsoft.com/kb/815645
En gros, si vous avez des espaces dans le chemin de .lib, c'est mauvais. Je ne sais pas si c'est ce qui se passe pour vous, mais semble raisonnablement possible.
Le correctif est soit 1) mettez la référence de la bibliothèque entre "guillemets", ou 2) ajoutez le chemin de la bibliothèque à vos répertoires de bibliothèque (Propriétés de configuration >> Répertoires VC++).
J'ai eu le même problème dans VS 2010 et VS 2012. Sur mon système, la première bibliothèque statique a été créée, puis immédiatement supprimée lorsque le projet principal a commencé à être créée.
Le problème est le dossier intermédiaire commun pour plusieurs projets. Assignez simplement un dossier intermédiaire distinct pour chaque projet.
En savoir plus sur ce ici
Je l'ai résolu avec ce qui suit:
Allez dans Affichage-> Pages de propriétés -> Propriétés de configuration -> Éditeur de liens -> Entrée
Sous dépendances supplémentaires, ajoutez le fichier thelibrary.lib. Ne pas utiliser de citations.
J'ai eu un problème similaire en ce sens que je recevais LINK1181 _ erreurs sur le .OBJ fichier qui faisait partie du projet lui-même (et il n'y avait que 2 fichiers .cxx dans l'ensemble du projet).
Au départ, j'avais configuré le projet pour générer un .EXE dans Visual Studio, puis dans le Property Pages -> Configuration Properties -> General -> Project Defaults -> Configuration Type, J'ai changé le fichier .EXE en .DLL. En pensant que Visual Studio 2008 était en train de devenir confus, j'ai recréé toute la solution en utilisant le mode .DLL dès le début. Le problème a disparu après cela. J'imagine que si vous sélectionniez manuellement votre chemin dans le fichier .vcproj et d'autres fichiers associés, vous pourriez comprendre comment régler le problème sans repartir à zéro (mon programme étant composé de deux fichiers .cpp, il était donc plus facile de tout recommencer).
Je ne sais pas pourquoi, mais j'ai changé le lien "Linker-> Input-> Additional Dependencies" de "dxguid.lib" en "C:\Program Files (x86)\SDK DirectX Microsoft (juin 2010)\Lib\x86\dxguid. lib "(dans mon cas) était la seule chose qui a fonctionné.
Je suis tombé sur le même problème. Pour moi, cela semble être causé par 2 projets portant le même nom, l'un dépendant de l'autre.
Par exemple, j'ai un projet nommé Foo qui produit Foo.lib. J'ai ensuite un autre projet nommé Foo qui produit Foo.exe et des liens dans Foo.lib.
J'ai regardé l'activité du fichier avec Process Monitor. Ce qui semble se passer est que Foo (lib) est construit en premier - ce qui est approprié car Foo (exe) est marqué comme dépendant de Foo (lib). Tout cela est correct et construit avec succès. Il est placé dans le répertoire de sortie - $ (OutDir) $ (TargetName) $ (TargetExt). Alors Foo (exe) est déclenché pour reconstruire. Eh bien, une reconstruction est un nettoyage suivi d'une construction. Il semble que l'étape "propre" de Foo.exe supprime Foo.lib du répertoire de sortie. Cela explique également pourquoi une "construction" ultérieure fonctionne - sans supprimer les fichiers de sortie.
Un bug dans VS je suppose.
Malheureusement, je n'ai pas de solution au problème car il s'agit d'une reconstruction. Une solution de contournement consiste à exécuter manuellement Clean, puis Build.
Pour moi, le problème était un mauvais répertoire include. Je ne sais pas pourquoi cela a causé l'erreur avec la bibliothèque apparemment manquante car le répertoire include ne contient que les fichiers d'en-tête. Et le répertoire de la bibliothèque avait le bon chemin.
La même erreur s'est produite lors de l'exécution de lib.exe à partir de cmd sous Windows avec une longue liste d'arguments. Apparemment, cmd.exe a une longueur de ligne maximale d’environ 8 000 caractères, ce qui a entraîné une modification des noms de fichiers à la fin de ce seuil, entraînant une erreur de nom de fichier erronée. ma solution était de couper la ligne. J'ai supprimé tous les chemins des noms de fichiers et ajouté un chemin unique en utilisant l'option/LIBPATH. par exemple:
/LIBPATH:absolute_path /OUT:outfilename filename1.obj filename2.obj ... filenameN.obj
Peut-être que vous avez un problème matériel.
J'ai eu le même problème sur mon ancien système (processeur AMD 1800 MHz, 1 Go RAM, Windows 7 Ultimate)], jusqu'à ce que j'ai changé le 2x 512 Mo de RAM à - 2x 1 Go de RAM. N'a eu aucun problème depuis. De plus, d'autres problèmes (mineurs) ont disparu. Devinez, ces deux modules de 512 Mo ne s'aiment pas beaucoup, parce que 2x 512 Mo + 1 Go ou 1x 512 Mo + 2x 1GB ne fonctionnait pas correctement non plus.
Dans mon cas, la bibliothèque était installée à l'aide du paquet NuGet (cpprestsdk) ET j'ai faussement ajouté la bibliothèque aux dépendances supplémentaires dans les paramètres de l'éditeur de liens. Il s'avère que le paquet fait tout pour vous.
L'éditeur de liens a ensuite essayé de trouver la bibliothèque dans le chemin de la bibliothèque et, bien sûr, ne l'a pas trouvée.
Après avoir supprimé la bibliothèque des dépendances supplémentaires, tout est bien compilé et lié.
J'ai trouvé une solution différente pour cela ...
En fait, j'ai manqué le séparateur de virgule entre deux chemins de bibliothèque. Après avoir ajouté commun, cela a fonctionné pour moi.
Aller à: Project properties -> Linker -> General -> Link Library Dependencies Sur ce chemin, assurez-vous que le chemin de la bibliothèque est correct.
Code précédent (With Bug - parce que j'ai oublié de séparer deux chemins de lib par une virgule):
<Link><AdditionalLibraryDirectories>..\..\Build\lib\$(Configuration)**..\..\Build\Release;**%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
Code après correction (Il suffit de séparer les bibliothèques par des virgules):
<Link><AdditionalLibraryDirectories>..\..\Build\lib\$(Configuration)**;..\..\Build\Release;**%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
J'espère que cela vous aidera.
J'ai eu le même problème. Résolu en définissant une macro OBJECTS contenant tous les objets de l'éditeur de liens, par exemple:
OBJECTS = target.exe kernel32.lib mylib.lib (etc)
Et puis en spécifiant $(OBJECTS) sur la ligne de commande de l'éditeur de liens.
Je n'utilise pas Visual Studio cependant, juste nmake et un fichier .MAK
Vous pouvez également résoudre le problème d'espaces sur le chemin en spécifiant le chemin de la bibliothèque au format DOS "8.3".
Pour obtenir le formulaire 8.3, faites (sur la ligne de commande):
DIR /AD /X
récursivement à tous les niveaux des répertoires.