compilador - gcc windows

Error de Gcc: gcc: error al intentar ejecutar ''cc1'': execvp: no existe tal archivo o directorio (16)

Amazon Linux: solucionando el problema de GCC

Dado que esto aparece como el primer resultado en Google, solo quería documentar mi experiencia con Amazon Linux. La instalación de gcc-c++.noarch solucionó el problema:

sudo yum install gcc-c++.noarch

He estado usando gcc con éxito en Linux Mint 12. Ahora recibo un error. Hace poco estuve haciendo algunas construcciones .so e instalé Clang no hace mucho tiempo, pero me he compilado correctamente desde esos dos eventos, por lo que no estoy seguro de qué ha cambiado. Usé el GUI Software Manager para eliminar e instalar gcc nuevamente, pero los resultados son los mismos:

~/code/c/ut: which gcc /usr/bin/gcc ~/code/c/ut: gcc -std=c99 -Wall -Wextra -g -c object.c gcc: error trying to exec ''cc1'': execvp: No such file or directory

1. Explicación

El mensaje de error le indicó que no se encontró la dependencia del tiempo de compilación, por lo que todo lo que necesita es instalar el paquete apropiado en su sistema (utilizando el administrador de paquetes, compilación desde las fuentes o de otra manera)

¿Qué es cc1 ?

cc1 es el comando interno que toma los archivos de lenguaje C preprocesados y los convierte en ensamblado. Es la parte real que compila C. Para C ++, hay cc1plus y otros comandos internos para diferentes idiomas.

tomado de esta respuesta por Alan Shutko .

2. Soluciones

Ubuntu / Linux Mint

sudo apt-get install --reinstall build-essential

Entorno Docker-alpino

Si se encuentra en el entorno docker-alpine , agregue esto:

RUN apk add alpine-sdk

a tu Dockerfile

Tomado de github

Asegúrese de que su GCC_EXEC_PREFIX(env) no se exporte y su PATH se exporte a la cadena de herramientas correcta.

En CentOS o Fedora

yum install gcc-c++

En Scientific Linux 6 (similar a CentOS 6-- SL ahora es reemplazado por CentOS, AIUI), tuve que usar /usr/sbin/prelink -av -mR que encontré sugerido en https://stelfox.net/blog/2014/08/dependency-prelink-issues/

Hasta que lo hice, recibí un error de cc1 gcc: error trying to exec ''cc1'': execvp: No such file or directory cuando intenté compilar, y gcc --version informó 4.2.2 en lugar de 4.4.7, a pesar de eso versión reportada por yum.

Puede o no estar relacionado, pero el sistema se había quedado sin espacio en / var

En debian / ubuntu solucioné este problema reinstalando build-essential :

sudo apt-get update sudo apt-get install --reinstall build-essential

Este podría ser también el mensaje de error que se muestra si intenta ejecutar binarios gcc de 32 bits en un sistema operativo de 64 bits y falta glibc de 32 bits. De acuerdo con este readme : "Para el sistema de 64 bits, se requieren libc y libncurses de 32 bits para ejecutar las herramientas". En este caso, no hay ningún problema con la ruta y se encuentra realmente cc1, pero se informa que falta como no hay glibc de 32 bits.

Esto se debe a que gcc llama a muchos otros ejecutables para el procesamiento completo de la entrada y cc1 no está en la ruta incluida.

En tipo de shell: -

whereis cc1

Si se encuentra cc1, mejor adelante y cree un enlace suave en el directorio de gcc; de lo contrario, implica que cc1 no está instalado y debe instalar gcc-c++ utilizando el administrador de paquetes.

Experimenté este problema en una instalación razonablemente nueva de Fedora 27. Intenté todas las otras sugerencias o sus equivalentes; al instalar los diversos paquetes dijo "ya está instalado" o instaló algo nuevo que no ayudó.

Reparado con

# dnf remove gcc # dnf install gcc gcc-c++

Experimenté esto poco después de compilar e instalar un nuevo GCC brillante - versión 8.1 - en RHEL 7. Al final, terminó siendo un problema de permisos; mi raíz umask fue el culpable. Eventualmente encontré cc1 escondido en /usr/local/libexec :

[root@nacelle gdb-8.1]# ls -l /usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.1.0/ | grep cc1 -rwxr-xr-x 1 root root 196481344 Jul 2 13:53 cc1

Sin embargo, los permisos en los directorios que llevaban allí no permitían mi cuenta de usuario estándar:

[root@nacelle gdb-8.1]# ls -l /usr/local/libexec/ total 4 drwxr-x--- 3 root root 4096 Jul 2 13:53 gcc [root@nacelle gdb-8.1]# ls -l /usr/local/libexec/gcc/ total 4 drwxr-x--- 3 root root 4096 Jul 2 13:53 x86_64-pc-linux-gnu [root@nacelle gdb-8.1]# ls -l /usr/local/libexec/gcc/x86_64-pc-linux-gnu/ total 4 drwxr-x--- 4 root root 4096 Jul 2 13:53 8.1.0

Un chmod recursivo rápido para agregar permisos de lectura / ejecución del mundo lo solucionó:

[root@nacelle 8.1.0]# cd /usr/local/libexec [root@nacelle lib]# ls -l | grep gcc drwxr-x--- 3 root root 4096 Jul 2 13:53 gcc [root@nacelle lib]# chmod -R o+rx gcc [root@nacelle lib]# ls -l | grep gcc drwxr-xr-x 3 root root 4096 Jul 2 13:53 gcc

¡Y ahora gcc puede encontrar cc1 cuando le pido que compile algo!

Lo que me ayudó fue utilizar llvm-gcc lugar:

ln -s $(which llvm-gcc) /usr/local/bin/gcc

Me encontré con un problema similar hoy: un compañero de trabajo no podía construir su software, pero yo podía construirlo. Cuando ejecutó gcc no pudo encontrar cc1 .

Su ruta ejecutable parecía razonable, pero el hecho de que no podía replicar fácilmente el error sugería algo en su entorno como causa.

Finalmente encontramos GCC_EXEC_PREFIX definido en su entorno que era el culpable y engañaba a gcc en la búsqueda de cc1 . Esto era parte de sus scripts de inicio de shell y estaba destinado a evitar una limitación en un sistema SPARC / Solaris que ya no está en uso. El problema se resolvió al no configurar esta variable de entorno.

http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html

Puede solucionarlo ejecutando esto: En Fedora:

sudo dnf install redhat-rpm-config

Solo para documentar mi problema con este problema, aunque parezca ser un ejemplo específico de otras respuestas; como un novato relativo siento que esto podría ayudar a otros.

Solución:

Agregué ''/ usr / bin'' al comienzo de PATH para una sola sesión usando PATH=''/usr/path/:$PATH'' y todo comenzó a funcionar bien.

Usé gedit para actualizar la ruta de forma permanente, después de asegurarme de que no rompería mis cadenas de herramientas regulares.

Explicación:

Tengo múltiples toolchains instalados en Ubuntu 14.04LTS y uso solo un par de forma regular. Cuando traté de usar gcc desde la línea de comando, el OP me describió el problema. ''/ usr / bin'' está en la RUTA pero está detrás de las otras ubicaciones de la cadena de herramientas. Resulta que el cc1 para esas otras cadenas de herramientas es incompatible con gcc.

Solucioné este problema instalando explícitamente g ++:

sudo apt-get install g++

Se encontró un problema en Ubuntu 12.04 al instalar pandas. (Gracias perilbrain.)

yum install gcc-c++ hizo la corrección.