Ik heb een nieuw C++-project gemaakt in Visual Studio 2008. Er is nog geen code geschreven; Alleen projectinstellingen zijn gewijzigd.
Als ik het project compileer, krijg ik de volgende fatale fout:
fatale fout LNK1104: kan bestand ‘C:\Program.obj’ niet openen
Antwoord 1, autoriteit 100%
Dit specifieke probleem wordt veroorzaakt door het specificeren van een afhankelijkheid van een lib-bestand met spaties in het pad. Het pad moet worden omgeven door aanhalingstekens om het project correct te compileren.
Op de Configuratie-eigenschappen -> Linker -> Invoertabblad van de projecteigenschappen, er is een Additional Dependencieseigenschap. Dit probleem is verholpen door deze eigenschap te wijzigen van:
C:\Program Files\software
sdk\lib\library.lib
Aan:
” C:\Program Files\software
sdk\lib\library.lib”
Waar ik de aanhalingstekens heb toegevoegd.
Antwoord 2, autoriteit 43%
Dit kan gebeuren als het bestand ook nog actief is.
:-1: fout: LNK1104: kan bestand ‘debug\****.exe’ niet openen
Antwoord 3, autoriteit 9%
Het probleem verdween voor mij na het sluiten en opnieuw openen van Visual Studio. Ik weet niet zeker waarom het probleem zich voordeed, maar dat is misschien het proberen waard.
Dit was op VS 2013 Ultimate, Windows 8.1.
Antwoord 4, autoriteit 6%
Controleer ook of dit niet is ingeschakeld: Configuratie-eigenschappen -> C/C++ -> Preprocessor -> Voorverwerken tot een bestand.
Antwoord 5, autoriteit 2%
Ik had hetzelfde probleem. Het werd veroorzaakt door een “,” in de naam van een map met een extra bibliotheekpad. Het werd opgelost door het extra bibliotheekpad te wijzigen.
Antwoord 6, autoriteit 2%
Mijn probleem was een ontbrekende .lib-extensie, ik linkte gewoon tegen myliben VS besloot te zoeken naar mylib.obj.
Antwoord 7, autoriteit 2%
In mijn geval was het een kwestie van een verkeerd gerichte verwijzing. Project verwees naar de uitvoer van een ander project, maar de laatste gaf niet het bestand weer waar de eerste naar op zoek was.
Antwoord 8, autoriteit 2%
Oplossing 1 (voor mijn geval): herstart Windows Verkenner-proces (ja, de Windows-bestandsbeheerder).
Oplossing 2:
- Sluit Visual Studio. Windows Afmelden
- Aanmelden, Visual Studio opnieuw openen
- Bouw zoals gewoonlijk. Het bouwt nu op en heeft toegang tot het problematische bestand.
Ik neem aan dat het bestandssysteem of degene die het beheert soms verloren gaat met zijn permissies. Alvorens de Windows-sessie opnieuw te starten, probeerde de zombie msbuild32.exe-processen te doden, Visual Studio opnieuw op te starten, geen enkele aan te vinken, zelfs het probleembestand aan te zetten. Geen problemen met de buildconfiguratie. Het gebeurt zo nu en dan. Een intern ding in Windows herstelt niet, moet opnieuw worden opgestart.
Antwoord 9
Ik had dezelfde fout, alleen met een Nuget-pakket dat ik had geïnstalleerd (een pakket dat niet alleen header is) en vervolgens probeerde te verwijderen.
Wat er mis voor mij was, was dat ik nog steeds een header voor het pakket dat ik zojuist had verwijderd in een van mijn .cpp-bestanden had opgenomen (behoorlijk dom, ja).
Ik heb zelfs de link naar de extra bibliotheekmappen verwijderd in Project -> Properties -> Linker -> General, maar het mocht natuurlijk niet baten omdat ik nog steeds probeerde te verwijzen naar de niet-bestaande header.
In dit geval zeker een verwarrende foutmelding, aangezien de headernaam <boost/filesystem.hpp>was, maar de fout gaf me "cannot open file 'llibboost_filesystem-vc140-mt-gd-1_59.lib'"en geen regelnummers of iets dergelijks.
Antwoord 10
Ik had hetzelfde probleem, maar de oplossing voor mijn geval wordt niet vermeld in de antwoorden.
Mijn antivirusprogramma (AVG) heeft bestand MyProg.exeals virus vastgesteld en in de ‘virusopslagplaats’ geplaatst. U moet dit magazijn controleren en als het bestand daar is, herstel het dan gewoon. Het heeft me geholpen.
Antwoord 11
Voor een assemblageproject (ProjectName -> Build Dependencies -> Build Customizations -> masm (geselecteerd)), veroorzaakte het instellen van Genereer voorverwerkte bronvermeldingop Truehet probleem voor mij ook, het wissen van de instelling loste het op. VS2013 hier.
Antwoord 12
Ik kom hetzelfde probleem tegen met een linker die klaagt over het ontbreken van het belangrijkste uitvoerbare bestand. Dit gebeurde tijdens onze oplossingsoverdracht naar de nieuwe Visual Studio 2013. De oplossing is een gevarieerde mix van beheerde en onbeheerde projecten/code. Het probleem (en de oplossing) was uiteindelijk een ontbrekend app.config-bestand in de oplossingsmap. Het kostte een dag om dit uit te zoeken :(, omdat het uitvoerlogboek niet erg nuttig was.
Antwoord 13
Ik heb al mijn instellingen gecontroleerd volgens deze lijst: http:// msdn.microsoft.com/en-us/library/ts7eyw4s.aspx#feedback. Het is nuttig voor mij en voor mijn situatie kom ik erachter dat Link Dependency van de eigenschappen van projecten een dubbel aanhalingsteken heeft, wat er niet zou moeten zijn.
Antwoord 14
in mijn geval was het de padlengte (incl. bestandsnaam).
..\..\..\..\..\..\..\SWX\Binary\VS2008\Output\Win32\Debug\boost_unit_test_framework-vc90-mt-gd-1_57.lib;
Wat betreft de release het pad was (dit heeft correct gewerkt):
..\..\..\..\..\..\..\SWX\Binary\VS2008\Output\Win32\Release\boost_unit_test_framework-vc90-mt-1_57.lib;
== & GT; één char korter.
- Ik heb dit ook geverifieerd door het Lib-bestand (met behulp van kortere naam) te hernoemen en dit in de
te veranderen
linker – & gt; Input – & GT; Additoinal-afhankelijkheden
- Ik heb dit ook geverifieerd door het toevoegen van Absolut Path in plaats van een relatief pad, zoals al die “..” heeft de padstring ook uitgebreid. Dit heeft ook gewerkt.
Dus het probleem voor mij was de totale grootte van het pad + bestandsnaamreeks was te lang!
Antwoord 15
Ik beantwoord omdat ik deze specifieke oplossing niet zie dat door iemand anders wordt vermeld.
Blijkbaar was mijn antivirus (AD-AUTO) een DLL-dll van mijn projecten markeren, is afhankelijk van en het verwijderen ervan. Zelfs na het uitsluiten van de map waar het DLL-leven woont, ging hetzelfde gedrag voort totdat ik mijn computer opnieuw opneemde.
Antwoord 16
In mijn geval had ik Math Library-bestanden vervangen van een vorige game-motorstructuurcursus met GLM. Het probleem was dat ik ze niet toevoegde aan het project binnen de Solution Explorer van Visual Studio (ook al waren ze in de projectrepository).
Antwoord 17
Ik had dit probleem in combinatie met de LNK2038-fout, volgde deze postom de RELEASE en de DEBUG DLL’s te scheiden. In dit proces had ik de hele map opgeschoond waarin deze afhankelijkheden zich bevonden.
Gelukkig had ik een back-up van al deze bestanden en kreeg ik het bestand waarvoor deze fout werd gegooid terug in de DEBUG-map om het probleem op te lossen. De foutcode was op de een of andere manier misleidend, omdat ik veel tijd moest besteden om weer bij deze tip uit een van de antwoorden uit dit bericht te komen.
Ik hoop dat dit antwoord iemand in nood helpt.
Antwoord 18
Ik heb het opgelost door toe te voegeneen bestaand projectaanmijn oplossing, die ik vergat te doen de eerste keer toevoegen.
Antwoord 19
Ik had dezelfde fout:
fatal error LNK1104: cannot open file 'GTest.lib;'
Dit werd veroorzaakt door de ;aan het einde. Als u meerdere bibliotheken heeft, moeten deze worden gescheiden door een lege ruimte (spatiebalk), geen komma’s of puntkomma’s!
Gebruik dus geen ;of iets anders bij het vermelden van bibliotheken in Projecteigenschappen >> Configuratie-eigenschappen >> Linker >> Invoer
Antwoord 20
Ik heb bovenstaande oplossing geprobeerd, maar werkte niet voor mij.
Dus ik hernoem de exe en herbouw de oplossing.
Het werkt voor mij.
Antwoord 21
Ik had exact deze fout bij het bouwen van een VC++ DLL in Visual Studio 2019:
LNK1104: kan bestand ‘C:\Program.obj’ niet openen
Buiten onder project Eigenschappen > Linker > Invoer > Moduledefinitiebestand, ik had een def-bestand gespecificeerd met een ongeëvenaarde dubbele aanhalingstekensaan het einde van de bestandsnaam. Het verwijderen van de ongeëvenaarde dubbele aanhalingstekens loste het probleem op.
Antwoord 22
Vermoord msbuild32.exeen opnieuw opgebouwd. Het werkte voor mij.
Antwoord 23
Mijn probleem werd veroorzaakt door een andere toepassing die het .dll-bestand gebruikte dat ik probeerde te debuggen.
Sluitende toepassing die de .dll gebruikte, loste het voor mij op.
Antwoord 24
Mogelijke oplossingen:
-
Controleer of het pad spaties bevat, Ga naar Eigenschappen > Linker > Invoer > extra pad en voeg “pad met witruimte” toe
-
Als het programma nog steeds actief is, sluit dan alles en start opnieuw.
-
Controleer of het .obj-bestand niet is gemaakt. Dit gebeurt wanneer u direct een project bouwt terwijl Properties > C++ > Preprocessor > Preprocessor-bestand genereren is ingeschakeld. Schakel het uit en bouw het project dan kunt u opn Eigenschappen > C++ > Preprocessor > Genereer preprocessor-bestand.
Antwoord 25
Ik heb hetzelfde probleem ondervonden met ‘Visual Studio 2013’.
LNK1104: cannot open file 'debug\****.exe
Het is opgelost na het sluiten en opnieuw opstarten van Visual Studio.
Antwoord 26
Ik had hetzelfde probleem, ik heb zojuist de code gekopieerd naar een nieuw project en ben begonnen met het bouwen.
Er begon een andere fout te komen.
fout C4996: ‘fopen’: deze functie of variabele is mogelijk onveilig. Overweeg om in plaats daarvan fopen_s te gebruiken
Om dit probleem opnieuw op te lossen, heb ik mijn enige eigenschap toegevoegd aan het projectproject, zoals hieronder.
Project – & GT; Eigenschappen – & GT; Configuratie-eigenschap – & GT; C / C++.
In deze categorie is er veldnaam PreProcessor Definities
Ik heb _crt_secure_no_warnings dit toegevoegd om het probleem op te lossen
Ik hoop dat het zal helpen …
Bedankt