Pourquoi l'erreur fatale "LNK1104: impossible d'ouvrir le fichier 'C: \ Program.obj'" se produit-elle lorsque je compile un projet C ++ dans Visual Studio?
J'ai créé un nouveau projet C++ dans Visual Studio 2008. Aucun code n'a encore été écrit. Seuls les paramètres du projet ont été modifiés.
Lorsque je compile le projet, le message d'erreur fatal suivant s'affiche:
erreur fatale LNK1104: impossible d'ouvrir le fichier 'C:\Program.obj'
Ce problème particulier est dû à la spécification d'une dépendance à un fichier lib contenant des espaces dans son chemin. Le chemin doit être entouré de guillemets pour que le projet puisse être compilé correctement.
L'onglet Propriétés de configuration -> Éditeur de liens -> Entrée des propriétés du projet contient une propriété dépendances supplémentaires. Ce problème a été résolu en modifiant cette propriété à partir de:
C:\Program Files\sdk logiciel\lib\library.lib
À:
"C:\Program Files\sdk logiciel\lib\library.lib"
Où j'ai ajouté les citations.
Cela peut arriver si le fichier est toujours en cours d'exécution.
: -1: erreur: LNK1104: impossible d'ouvrir le fichier 'debug\****. Exe'
Le problème est parti pour moi après la fermeture et la réouverture de Visual Studio. Je ne sais pas pourquoi le problème est arrivé, mais cela pourrait valoir le coup.
C'était sur VS 2013 Ultimate, Windows 8.1.
Vérifiez également que cette option n'est pas activée: Propriétés de la configuration -> C/C++ -> Préprocesseur -> Prétraitement dans un fichier.
Mon problème était une extension manquante de .lib, j'étais juste en train de lier contre mylib et VS a décidé de rechercher mylib.obj.
J'ai eu le même problème.Il a été provoqué par un "," au nom d'un dossier de chemin de bibliothèque supplémentaire.Il a été résolu en modifiant le chemin de bibliothèque supplémentaire.
Dans mon cas, il s'agissait d'une référence mal dirigée. Le projet a référencé la sortie d’un autre projet, mais ce dernier n’a pas généré le fichier recherché.
J'ai vérifié tous mes paramètres en fonction de cette liste: http://msdn.Microsoft.com/en-us/library/ts7eyw4s.aspx#feedback . Cela m’aide et, dans mon cas, j’apprends que la dépendance de liens des propriétés des projets comporte des guillemets, ce qui ne devrait pas exister.
J'ai eu la même erreur, juste avec un paquet de Nuget que j'avais installé (un qui n'est pas en-tête seulement) et ensuite essayé de désinstaller.
Ce qui ne va pas, c’est que j’incluais toujours un en-tête pour le paquet que je venais de désinstaller dans l’un de mes fichiers .cpp (plutôt idiot, oui).
J'ai même supprimé les liens vers les répertoires de bibliothèque supplémentaires dans Project -> Properties -> Linker -> General, mais bien sûr, en vain, car j'essayais toujours de référencer l'en-tête inexistant.
Dans ce cas, il s’agit clairement d’un message d’erreur déroutant, puisque le nom de l’en-tête était <boost/filesystem.hpp> mais que l’erreur me donnait "cannot open file 'llibboost_filesystem-vc140-mt-Gd-1_59.lib'" et qu’aucun numéro de ligne ou quoi que ce ne soit.
Solution 1 (dans mon cas): redémarrez le processus Windows Explorer (oui, le gestionnaire de fichiers Windows).
Solution 2:
- Fermez Visual Studio. Fermeture de session Windows
- Ouvrir une session, rouvrir Visual Studio
- Construire comme d'habitude. Il construit maintenant et peut accéder au fichier problématique.
Je présume parfois que le système de fichiers ou celui qui le contrôle se perd avec ses autorisations. Avant de redémarrer la session Windows, essayez de tuer les processus zombie msbuild32.exe, redémarrez Visual Studio et ne cochez aucune case pour afficher le fichier posant problème. Aucun problème de configuration de construction. Cela arrive de temps en temps. Un problème interne à Windows ne résout pas le problème, nécessite un redémarrage.
J'ai eu le même problème, mais la solution à mon cas ne figure pas dans les réponses. Mon programme antivirus (AVG) a identifié le fichier MyProg.exe en tant que virus et l'a placé dans le "magasin de virus". Vous devez vérifier cet entrepôt et s'il y a un fichier - restaurez-le simplement. Cela m'a aidé.
Pour un projet d'assemblage (ProjectName -> Construire des dépendances -> Construire des personnalisations -> masm (sélectionné)), paramètre Générer une liste source prétraitée à True m'a aussi causé le problème, effacer le réglage corrigé. VS2013 ici.
Je rencontre le même problème avec l'éditeur de liens qui se plaint du fichier exécutable principal manquant. Cela s'est produit lors du port de notre solution vers le nouveau Visual Studio 201. La solution consiste en un mélange varié de projets/codes gérés et non gérés. Le problème (et le correctif) a fini par être un fichier app.config manquant dans le dossier de la solution. A pris une journée pour comprendre celui-ci :(, comme journal de sortie n'était pas très utile.
J'ai eu ce problème en même temps que l'erreur LNK2038, suivi ceci post pour séparer les DLL RELEASE et DEBUG. Dans ce processus, j'avais nettoyé tout le dossier où résidaient ces dépendances.
Heureusement, j’ai eu une sauvegarde de tous ces fichiers et j’ai eu le fichier pour lequel cette erreur était renvoyée dans le dossier DEBUG afin de résoudre le problème. Le code d'erreur était trompeur, car je devais passer beaucoup de temps à trouver cette astuce à partir de l'une des réponses de ce billet.
J'espère que cette réponse aidera quelqu'un dans le besoin.
J'ai eu la même erreur:
fatal error LNK1104: cannot open file 'GTest.lib;'
Cela a été causé par le ; à la fin. Si vous avez plusieurs bibliothèques, elles doivent être séparées par un espace vide (barre d'espace), sans virgule ni point-virgule!
Donc, n’utilisez pas ; ou quoi que ce soit d’autre pour lister des bibliothèques dans Project properties >> Configuration Properties >> Linker >> Input
Dans mon cas, j'avais remplacé les fichiers de la bibliothèque de mathématiques d'un cours précédent Game Engine Graphics par GLM. Le problème était que je ne les avais pas ajoutés au projet dans l'Explorateur de solutions de Visual Studio (même s'ils se trouvaient dans le référentiel du projet).
Je rencontre le même problème avec "Visual Studio 2013".
LNK1104: cannot open file 'debug\****.exe
Il s'est résolu après la fermeture et le redémarrage de Visual studio.
Je réponds parce que je ne vois pas cette solution particulière énumérée par quelqu'un d'autre.
Apparemment, mon antivirus (Ad-Aware) signalait un DLL dont l'un des projets dépend et le supprimait. Même après avoir exclu le répertoire où réside la DLL, le même comportement a continué jusqu'à ce que je redémarre mon ordinateur.
Je l'ai résolu par ajoutant un projet existantà mon solution, que je j'ai oublié d'ajouter dans la première fois.