Por que o erro fatal “LNK1104: não é possível abrir o arquivo 'C: \ Program.obj'” ocorre quando eu compilo um projeto C ++ no Visual Studio?

Criei um novo projeto C ++ no Visual Studio 2008. Nenhum código foi escrito ainda; Apenas as configurações do projeto foram alteradas.

Ao compilar o projeto, recebo o seguinte erro fatal:

erro fatal LNK1104: não é possível abrir o arquivo 'C: \ Program.obj'

Esse problema específico é causado pela especificação de uma dependência de um arquivo lib que tinha espaços em seu caminho. O caminho precisa estar entre aspas para que o projeto seja compilado corretamente.

Em Propriedades de Configuração -> Vinculador -> guia Entrada das propriedades do projeto, há uma propriedade Dependências Adicionais . Este problema foi corrigido alterando esta propriedade de:

C: \ Arquivos de programas \ sofware sdk \ lib \ library.lib

Para:

"C: \ Arquivos de programas \ sofware sdk \ lib \ library.lib"

Onde eu adicionei as aspas.

Isso pode acontecer se o arquivo ainda estiver em execução.

: -1: erro: LNK1104: não é possível abrir o arquivo 'debug \ ****. Exe'

O problema foi embora para mim depois de fechar e reabrir o Visual Studio. Não sei por que o problema aconteceu, mas vale a pena tentar.

Isso foi no VS 2013 Ultimate, Windows 8.1.

Verifique também se isso não está ativado: Propriedades de configuração -> C / C ++ -> Pré-processador -> Pré-processar para um arquivo .

Eu tive o mesmo problema.É causado por um "," no nome de uma pasta de caminho de biblioteca adicional. Resolvido alterando o caminho de biblioteca adicional.

Meu problema era uma .libextensão faltando , eu estava apenas ligando mylibe o VS decidiu procurar mylib.obj.

No meu caso, trata-se de uma referência mal direcionada. O projeto fez referência à saída de outro projeto, mas o último não gerou o arquivo que o primeiro estava procurando.

Solução 1 (para o meu caso): reinicie o processo do Windows Explorer (sim, o gerenciador de arquivos do Windows).

Solução 2:

1. Feche o Visual Studio. Logoff do Windows
2. Faça logon, reabra o Visual Studio
3. Construa como de costume. Agora ele cria e pode acessar o arquivo problemático.

Presumo que às vezes o sistema de arquivos ou quem o está controlando se perde com suas permissões. Antes de reiniciar a sessão do windows, tente matar msbuild32.exeprocessos zumbis , reinicie o visual studio, marque nenhum mesmo mostrando o arquivo com problema. Sem problemas de configuração de compilação. Acontece de vez em quando. Alguma coisa interna do Windows não conserta, precisa ser reiniciada.

Eu tive o mesmo erro, apenas com um pacote Nuget que instalei (um que não é apenas cabeçalho) e tentei desinstalar.
O que estava errado para mim era que eu ainda estava incluindo um cabeçalho para o pacote que acabei de desinstalar em um dos meus arquivos .cpp (muito bobo, sim).
Até removi o link de diretórios de biblioteca adicional para ele Project -> Properties -> Linker -> General, mas é claro que não adiantou, pois ainda estava tentando fazer referência ao cabeçalho inexistente.

Definitivamente, uma mensagem de erro confusa neste caso, já que o nome do cabeçalho era, <boost/filesystem.hpp>mas o erro me deu "cannot open file 'llibboost_filesystem-vc140-mt-gd-1_59.lib'"e nenhum número de linha ou nada.

Tive o mesmo problema, mas a solução para o meu caso não consta nas respostas. Meu programa antivírus (AVG) determinou o arquivo MyProg.execomo um vírus e o colocou no 'depósito de vírus'. Você precisa verificar este depósito e se o arquivo está lá - então apenas restaure-o. Isso me ajudou.

Para um projeto de montagem (ProjectName -> Build Dependencies -> Build Customizations -> masm (selected)), configurar Generate Preprocessed Source Listing como True causou o problema para mim também, limpando a configuração que corrigiu. VS2013 aqui.

Tive o mesmo problema com o vinculador reclamando da falta do executável principal. Isso aconteceu durante a conversão da nossa solução para o novo Visual Studio 2013 . A solução é uma mistura variada de projetos / códigos gerenciados e não gerenciados. O problema (e a correção) acabou sendo um arquivo app.config ausente na pasta da solução. Demorou um dia para descobrir isso :(, pois o log de saída não foi muito útil.

Verifiquei todas as minhas configurações de acordo com esta lista: http://msdn.microsoft.com/en-us/library/ts7eyw4s.aspx#feedback . É útil para mim e para minha situação, descobrir que Link Dependency of projects 'properties tem aspas duplas, que não deveriam estar lá.

Estou respondendo porque não vejo essa solução específica listada por mais ninguém.

Aparentemente, meu antivírus (Ad-Aware) estava sinalizando uma DLL da qual depende um dos meus projetos e excluindo-a. Mesmo depois de excluir o diretório onde está a DLL, o mesmo comportamento continuou até que reiniciei meu computador.

No meu caso, substituí os arquivos da biblioteca matemática de um curso anterior de gráficos do Game Engine pelo GLM. O problema é que não os adicionei ao projeto dentro do Solution Explorer do Visual Studio (mesmo que estivessem no repositório do projeto).

Tive esse problema em conjunto com o erro LNK2038, acompanhei este post para separar as DLLs RELEASE e DEBUG. Neste processo, limpei toda a pasta onde residiam essas dependências.

Felizmente, eu tinha um backup de todos esses arquivos e recuperei o arquivo cujo erro estava sendo gerado na pasta DEBUG para resolver o problema. O código de erro foi enganoso de alguma forma, já que tive que gastar muito tempo para chegar a esta dica de uma das respostas deste post novamente.

Espero que esta resposta, ajude alguém em necessidade.

Resolvi isso adicionando um projeto existente à minha solução , que esqueci de adicionar na primeira vez.

Eu tive o mesmo erro:

fatal error LNK1104: cannot open file 'GTest.lib;'

Isso foi causado pelo ;no final. Se você tiver várias bibliotecas, elas devem ser separadas por um espaço vazio (barra de espaço), sem vírgula ou ponto-e-vírgula!

Portanto, não use ;ou qualquer outra coisa ao listar bibliotecas emProject properties >> Configuration Properties >> Linker >> Input

Eu tentei a solução acima, mas não funcionou para mim. Então, eu renomeio o exe e reconstruo a solução. Funciona para mim.

Eu tive este erro exato ao criar uma DLL VC ++ no Visual Studio 2019:

LNK1104: não é possível abrir o arquivo 'C: \ Program.obj'

Descoberto em Propriedades do projeto> Linker> Entrada> Arquivo de definição de módulo, especifiquei um arquivo def que tinha aspas duplas incomparáveis no final do nome do arquivo. Excluir a aspa dupla incomparável resolveu o problema.

Morto msbuild32.exee construído novamente. Funcionou para mim

Eu tive o mesmo problema com "Visual Studio 2013".

LNK1104: cannot open file 'debug\****.exe

Foi resolvido após fechar e reiniciar o Visual Studio.

Eu estava tendo o mesmo problema, acabei de copiar o código para o novo projeto e iniciar a compilação. Algum outro erro começou a chegar. erro C4996: 'fopen': esta função ou variável pode não ser segura. Considere usar fopen_s ao invés

Para resolver este problema novamente, adicionei minha única propriedade no projeto Project conforme abaixo. Projeto -> Propriedades -> Propriedade de configuração -> c / c ++. Nesta categoria, há o nome do campo Definições de pré-processador. Eu adicionei _CRT_SECURE_NO_WARNINGS para resolver o problema. Espero que ajude ...

Obrigado