¿Por qué ocurre el error fatal “LNK1104: no se puede abrir el archivo 'C: \ Program.obj'” cuando compilo un proyecto de C ++ en Visual Studio?

He creado un nuevo proyecto de C ++ en Visual Studio 2008. Aún no se ha escrito ningún código; Solo se ha cambiado la configuración del proyecto.

Cuando compilo el proyecto, recibo el siguiente error fatal:

error fatal LNK1104: no se puede abrir el archivo 'C: \ Program.obj'

Este problema en particular se debe a la especificación de una dependencia a un archivo lib que tenía espacios en su ruta. La ruta debe estar rodeada de comillas para que el proyecto se compile correctamente.

En las Propiedades de configuración -> Vinculador -> pestaña Entrada de las propiedades del proyecto, hay una propiedad Dependencias adicionales . Este problema se solucionó cambiando esta propiedad de:

C: \ Archivos de programa \ sofware sdk \ lib \ library.lib

A:

"C: \ Archivos de programa \ sofware sdk \ lib \ library.lib"

Donde agregué las citas.

Esto puede suceder si el archivo todavía se está ejecutando.

: -1: error: LNK1104: no se puede abrir el archivo 'debug \ ****. Exe'

El problema desapareció después de cerrar y volver a abrir Visual Studio. No estoy seguro de por qué ocurrió el problema, pero valdría la pena intentarlo.

Esto fue en VS 2013 Ultimate, Windows 8.1.

Compruebe también que no tiene esto activado: Propiedades de configuración -> C / C ++ -> Preprocesador -> Preprocesar a un archivo .

Tuve el mismo problema. Fue causado por un "," en el nombre de una carpeta de ruta de biblioteca adicional. Se resolvió cambiando la ruta de biblioteca adicional.

Mi problema era que faltaba una .libextensión, solo estaba enlazando myliby VS decidió buscar mylib.obj.

En mi caso, se trató de una referencia mal dirigida. El proyecto hizo referencia a la salida de otro proyecto, pero este último no dio salida al archivo donde estaba buscando el primero.

Solución 1 (para mi caso): reinicie el proceso del Explorador de Windows (sí, el administrador de archivos de Windows).

Solución 2:

1. Cierre Visual Studio. Cierre de sesión de Windows
2. Iniciar sesión, volver a abrir Visual Studio
3. Construye como de costumbre. Ahora compila y puede acceder al archivo problemático.

Supongo que a veces el sistema de archivos o quien lo controla se pierde con sus permisos. Antes de reiniciar la sesión de Windows, trató de matar los msbuild32.exeprocesos zombies , reinicie Visual Studio, no marque ninguno que muestre el archivo problemático. Sin problemas de configuración de compilación. Sucede de vez en cuando. Algo interno de Windows no se soluciona, necesita reiniciarse.

Tuve el mismo error, solo con un paquete de Nuget que había instalado (uno que no es solo encabezado) y luego intenté desinstalarlo.
Lo que estaba mal para mí fue que todavía estaba incluyendo un encabezado para el paquete que acabo de desinstalar en uno de mis archivos .cpp (bastante tonto, sí).
Incluso eliminé el enlace de los directorios adicionales de la biblioteca Project -> Properties -> Linker -> General, pero, por supuesto, fue en vano ya que todavía estaba tratando de hacer referencia al encabezado inexistente.

Definitivamente un mensaje de error confuso en este caso, ya que el nombre del encabezado era <boost/filesystem.hpp>pero el error me dio "cannot open file 'llibboost_filesystem-vc140-mt-gd-1_59.lib'"y no había números de línea ni nada.

Tuve el mismo problema, pero la solución para mi caso no aparece en las respuestas. Mi programa antivirus (AVG) determinó el archivo MyProg.execomo un virus y lo colocó en el "almacén de virus". Debe verificar este almacén y, si el archivo está allí, simplemente restaurelo. Me ayudó.

Para un proyecto de ensamblaje (Nombre del proyecto -> Dependencias de compilación -> Personalizaciones de compilación -> masm (seleccionado)), establecer Generar lista de fuentes preprocesadas en Verdadero también me causó el problema, borrar la configuración lo solucionó. VS2013 aquí.

Me encuentro con el mismo problema con el vinculador quejándose de que falta el ejecutable principal. Esto sucedió durante el puerto de nuestra solución al nuevo Visual Studio 2013 . La solución es una mezcla variada de proyectos / código administrados y no administrados. El problema (y la solución) terminó siendo un archivo app.config faltante en la carpeta de la solución. Me tomó un día resolver esto :(, ya que el registro de salida no fue muy útil.

Revisé todas mis configuraciones de acuerdo con esta lista: http://msdn.microsoft.com/en-us/library/ts7eyw4s.aspx#feedback . Es útil para mí y para mi situación, descubro que las propiedades de los proyectos de dependencia de enlaces tienen comillas dobles, que no deberían estar allí.

Respondo porque no veo esta solución en particular en la lista de nadie más.

Aparentemente, mi antivirus (Ad-Aware) estaba marcando una DLL de la que uno de mis proyectos depende y eliminándola. Incluso después de excluir el directorio donde vive la DLL, el mismo comportamiento continuó hasta que reinicié mi computadora.

En mi caso, reemplacé los archivos de la biblioteca matemática de un curso anterior de Game Engine Graphics con GLM. El problema fue que no los agregué al proyecto dentro del Explorador de soluciones de Visual Studio (a pesar de que estaban en el repositorio del proyecto).

Tuve este problema junto con el error LNK2038, seguí esta publicación para segregar las DLL de RELEASE y DEBUG. En este proceso, había limpiado toda la carpeta donde residían estas dependencias.

Afortunadamente, tenía una copia de seguridad de todos estos archivos y obtuve el archivo para el cual este error estaba devolviendo a la carpeta DEBUG para resolver el problema. El código de error fue engañoso de alguna manera, ya que tuve que dedicar mucho tiempo a llegar a este consejo de una de las respuestas de esta publicación nuevamente.

Espero que esta respuesta ayude a alguien que lo necesite.

Lo resolví agregando un proyecto existente a mi solución , que olvidé agregar la primera vez.

Yo tenía el mismo error:

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

Esto fue causado por el ;al final. Si tiene varias bibliotecas, deben estar separadas por un espacio vacío (barra espaciadora), ¡sin comas ni punto y coma!

Así que no use ;ni nada más cuando enumere las bibliotecas enProject properties >> Configuration Properties >> Linker >> Input

Intenté la solución anterior pero no funcionó para mí. Así que cambio el nombre del exe y reconstruyo la solución. Esto funciona para mi.

Tuve este error exacto al construir una DLL de VC ++ en Visual Studio 2019:

LNK1104: no se puede abrir el archivo 'C: \ Program.obj'

Resultó que en Propiedades del proyecto> Vinculador> Entrada> Archivo de definición de módulo, había especificado un archivo def que tenía una comilla doble inigualable al final del nombre del archivo. La eliminación de las comillas dobles no coincidentes resolvió el problema.

Asesinado msbuild32.exey construido de nuevo. Funcionó para mí.

Tuve el mismo problema con "Visual Studio 2013".

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

Se resolvió después de cerrar y reiniciar Visual Studio.

Estaba teniendo el mismo problema, acabo de copiar el código en un nuevo proyecto y comencé la compilación. Comenzó a aparecer algún otro error. error C4996: 'fopen': esta función o variable puede no ser segura. Considere usar fopen_s en su lugar

Para resolver este problema nuevamente, agregué mi única propiedad en el proyecto del Proyecto como se muestra a continuación. Proyecto -> Propiedades -> Propiedad de configuración -> c / c ++. En esta categoría hay un nombre de campo Preprocesador Definiciones He agregado _CRT_SECURE_NO_WARNINGS esto para resolver el problema Espero que ayude ...

Gracias