Pourquoi l'erreur fatale LNK1104: ne peut-elle pas ouvrir le fichier 'C: \ Program.obj' & # 8221; se passe-t-il lorsque je compile un projet C ++ dans Visual Studio?
https://stackoverflow.com/questions/133698
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
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'
La solution
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.
Sur les Propriétés de configuration - > Lieur - > Dans l'onglet des propriétés du projet, il existe une propriété Dépendances supplémentaires . Ce problème a été résolu en modifiant cette propriété à partir de:
C: \ Program Files \ logiciel sdk \ lib \ library.lib
À:
" C: \ Program Files \ logiciel sdk \ lib \ library.lib "
Où j'ai ajouté les guillemets.
Autres conseils
Cela peut arriver si le fichier est également 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 configuration - > C / C ++ - > Préprocesseur - > Prétraiter un fichier .
J'ai eu le même problème.Il a été causé 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.
Mon problème résidait dans une extension .lib manquante; je ne faisais que mettre un lien contre mylib et VS a décidé de rechercher mylib.obj .
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é.
Pour un projet d'assemblage (ProjectName - > Construire des dépendances - > Construire des personnalisations - > masm (sélectionné)), définissez Générer la liste des sources prétraitées sur True . le problème pour moi aussi, effacer le paramètre 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 transfert de notre solution vers le nouveau Visual Studio 2013 . 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) finissait par être un fichier app.config manquant dans le dossier de la solution. Il a fallu une journée pour comprendre celui-ci :(, car le journal de sortie n’était pas très utile.
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, je découvre 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, mais avec un paquetage Nuget que j'avais installé (un fichier qui n'est pas en-tête uniquement), puis que j'ai essayé de désinstaller.
Ce qui n'allait pas pour moi, c'est que je continuais d'inclure un en-tête pour le paquet que je venais de désinstaller dans l'un de mes fichiers .cpp (assez stupide, oui).
J'ai même supprimé les liens vers les répertoires de bibliothèque supplémentaires dans Projet - > Propriétés - > Lieur - > Général , mais bien sûr en vain puisque je cherchais encore à référencer l’en-tête inexistant.
Il s'agit certainement d'un message d'erreur déroutant dans ce cas, puisque le nom de l'en-tête était < boost / filesystem.hpp > mais que l'erreur m'a donné " ne peut pas ouvrir le fichier 'llibboost_filesystem-vc140- mt-gd-1_59.lib '" > et aucun numéro de ligne ou quoi que ce soit.
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é.
Solution 1 (dans mon cas): redémarrez le processus de l'explorateur Windows (oui, le gestionnaire de fichiers Windows).
Solution 2:
- Fermez Visual Studio. Fermeture de session Windows
- Connexion, rouvrez Visual Studio
- Construisez comme d'habitude. Il construit maintenant et peut accéder au fichier problématique.
Je suppose 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, cochez-en aucun pour montrer 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.
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) marquait une DLL dont dépend l'un de mes projets et la supprimait. Même après avoir exclu le répertoire contenant la DLL, le même comportement s’est poursuivi jusqu’à ce que je redémarre mon ordinateur.
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).
J'ai eu ce problème en même temps que l'erreur LNK2038, suivi cette 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 d'une certaine manière car j'ai dû passer beaucoup de temps à trouver cette astuce à partir de l'une des réponses de cet article.
J'espère que cette réponse aidera quelqu'un dans le besoin.
Je l'ai résolu en ajoutant un projet existant à ma solution , à laquelle j'ai oublié de] ajoutez dans la première fois.
J'ai eu la même erreur:
fatal error LNK1104: cannot open file 'GTest.lib;'
Ceci est dû au ; à la fin. Si vous avez plusieurs bibliothèques, elles doivent être séparées par un espace vide (barre d'espacement), sans virgule ni point-virgule!
N'utilisez donc pas ; ni quoi que ce soit d'autre pour répertorier les bibliothèques dans Propriétés du projet > > Propriétés de configuration > > Lieur > > Entrée
Je rencontre le même problème avec "Visual Studio 2013".
LNK1104: cannot open file 'debug\****.exe
Il a été résolu après la fermeture et le redémarrage de Visual studio.
J'avais le même problème, je viens de copier le code dans un nouveau projet et de démarrer la construction. Une autre erreur a commencé à venir. erreur C4996: 'fopen': cette fonction ou cette variable peut être dangereuse. Pensez à utiliser fopen_s à la place
Pour résoudre à nouveau ce problème, j'ai ajouté la propriété one ci-dessous dans le projet. Projet - > Propriétés - > Propriété de configuration - > c / c ++. Dans cette catégorie, il y a le nom du champ Définitions du préprocesseur J'ai ajouté _CRT_SECURE_NO_WARNINGS ceci pour résoudre le problème J'espère que ça va aider ...
Merci
