Instalación de GCC desde Linux desde cero por OnWorks

Ir al contenido

6.21.1. Instalación de GCC

Si se basa en x86_64, cambie el nombre del directorio predeterminado para las bibliotecas de 64 bits a "lib":

caso $ (uname -m) en x86_64)

sed -e '/ m64 = / s / lib64 / lib /' \

-i.orig gcc / config / i386 / t-linux64

;;

esac

caso $ (uname -m) en x86_64)

sed -e '/ m64 = / s / lib64 / lib /' \

-i.orig gcc / config / i386 / t-linux64

;;

esac

La documentación de GCC recomienda compilar GCC en un directorio de compilación dedicado:

mkdir -v construir cd construir

Prepare GCC para la compilación:

SED = sed \

../configure --prefix = / usr \

--enable-languages = c, c ++ \

--disable-multilib\

--disable-arranque \

--con-sistema-zlib

SED = sed \

../configure --prefix = / usr \

--enable-languages = c, c ++ \

--disable-multilib\

--disable-arranque \

--con-sistema-zlib

Tenga en cuenta que para otros idiomas, existen algunos requisitos previos que aún no están disponibles. Consulte el Libro BLFS para obtener instrucciones sobre cómo crear todos los idiomas admitidos por GCC.

El significado de los nuevos parámetros de configuración:

SED = sed

Establecer esta variable de entorno evita una ruta codificada de forma rígida a / tools / bin / sed.

--con-sistema-zlib

Este interruptor le dice a GCC que se vincule a la copia instalada en el sistema de la biblioteca Zlib, en lugar de a su propia copia interna.

imagen

Compila el paquete:

“piensen de nuevo sobre los incrementos de precio”

Importante:

En esta sección, el conjunto de pruebas para GCC se considera fundamental. No lo omita bajo ninguna circunstancia.

Importante:

En esta sección, el conjunto de pruebas para GCC se considera fundamental. No lo omita bajo ninguna circunstancia.

Se sabe que un conjunto de pruebas en el conjunto de pruebas de GCC agota la pila, así que aumente el tamaño de la pila antes de ejecutar las pruebas:

ulimit-s 32768

Pruebe los resultados como usuario sin privilegios, pero no se detenga ante los errores:

chown -Rv nadie.

su nadie -s / bin / bash -c "RUTA = $ RUTA make -k check"

chown -Rv nadie.

su nadie -s / bin / bash -c "RUTA = $ RUTA make -k check"

Para recibir un resumen de los resultados de la suite de pruebas, ejecute:

../contrib/test_summary

Solo para los resúmenes, canalice la salida a través de grep -A7 suma.

Los resultados se pueden comparar con los que se encuentran en http://www.linuxfromscratch.org/lfs/build-logs/9.0/ y https: //gcc.gnu. org / ml / gcc-testresults /.

Se sabe que fallan seis pruebas relacionadas con get_time. Estos aparentemente están relacionados con la configuración regional en_HK.

Se sabe que dos pruebas llamadas lookup.cc y reverse.cc en experimental / net fallan en el entorno chroot LFS porque requieren / etc / hosts e iana-etc.

Se sabe que dos pruebas denominadas pr57193.cy pr90178.c fallan.

No siempre se pueden evitar algunos fallos inesperados. Los desarrolladores de GCC suelen estar al tanto de estos problemas, pero aún no los han resuelto. A menos que los resultados de la prueba sean muy diferentes de los de la URL anterior, es seguro continuar.

Instale el paquete y elimine un directorio innecesario:

make install

rm -rf / usr / lib / gcc / $ (gcc -dumpmachine) /9.2.0/include-fixed/bits/

make install

rm -rf / usr / lib / gcc / $ (gcc -dumpmachine) /9.2.0/include-fixed/bits/

El directorio de compilación de GCC es propiedad de nadie ahora y la propiedad del directorio de encabezado instalado (y su contenido) será incorrecta. Cambiar la propiedad a raíz usuario y grupo:

chown -v -R root: root \

/usr/lib/gcc/*linux-gnu/9.2.0/include{,-arreglado}

chown -v -R root: root \

/usr/lib/gcc/*linux-gnu/9.2.0/include{,-arreglado}

Cree un enlace simbólico requerido por la FHS por razones "históricas".

ln -sv ../usr/bin/cpp / lib

Muchos paquetes usan el nombre cc para llamar al compilador de C. Para satisfacer esos paquetes, cree un enlace simbólico:

ln -sv gcc / usr / bin / cc

Agregue un enlace simbólico de compatibilidad para habilitar la creación de programas con Optimización de tiempo de enlace (LTO):

instalar -v -dm755 / usr / lib / bfd-plugins

ln -sfv ../../libexec/gcc/$(gcc -dumpmachine) /9.2.0/liblto_plugin.so \

/ usr / lib / bfd-plugins /

instalar -v -dm755 / usr / lib / bfd-plugins

ln -sfv ../../libexec/gcc/$(gcc -dumpmachine) /9.2.0/liblto_plugin.so \

/ usr / lib / bfd-plugins /

Ahora que nuestra cadena de herramientas final está en su lugar, es importante asegurarse nuevamente de que la compilación y la vinculación funcionen como se espera. Hacemos esto realizando las mismas comprobaciones de cordura que hicimos anteriormente en el capítulo:

echo 'int main () {}'> dummy.c

cc dummy.c -v -Wl, - detallado &> dummy.log readelf -l a.out | grep ': / lib'

echo 'int main () {}'> dummy.c

cc dummy.c -v -Wl, - detallado &> dummy.log readelf -l a.out | grep ': / lib'

No debería haber errores, y el resultado del último comando será (permitiendo diferencias específicas de la plataforma en el nombre del enlazador dinámico):

[Solicita el intérprete del programa: /lib64/ld-linux-x86-64.so.2]

Ahora asegúrese de que estemos configurados para usar los archivos de inicio correctos:

grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log

La salida del último comando debería ser:

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crt1.o tuvo éxito

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crti.o tuvo éxito

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crtn.o tuvo éxito

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crt1.o tuvo éxito

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crti.o tuvo éxito

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crtn.o tuvo éxito

Dependiendo de la arquitectura de su máquina, lo anterior puede diferir ligeramente, la diferencia suele ser el nombre del directorio después / usr / lib / gcc. Lo importante a buscar aquí es que gcc ha encontrado los tres crt * .o archivos bajo el / Usr / lib directorio.

Verifique que el compilador esté buscando los archivos de encabezado correctos:

grep -B4 '^ / usr / include' dummy.log

Este comando debería devolver el siguiente resultado:

#include <...> la búsqueda comienza aquí:

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/incluir

/ usr / local / include

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include-fixed

/ usr / include

#include <...> la búsqueda comienza aquí:

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/incluir

/ usr / local / include

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include-fixed

/ usr / include

Nuevamente, tenga en cuenta que el directorio que lleva el nombre de su triplete de destino puede ser diferente al anterior, dependiendo de su arquitectura.

A continuación, verifique que el nuevo vinculador se esté utilizando con las rutas de búsqueda correctas:

grep 'SEARCH. * / usr / lib' dummy.log | sed 's |; | \ n | g '

Las referencias a rutas que tienen componentes con '-linux-gnu' deben ignorarse, pero de lo contrario, la salida del último comando debe ser:

SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64") SEARCH_DIR("/usr/local/lib64") SEARCH_DIR("/lib64")

SEARCH_DIR ("/ usr / lib64") SEARCH_DIR ("/ usr / x86_64-pc-linux-gnu / lib") SEARCH_DIR ("/ usr / local / lib") SEARCH_DIR ("/ lib")

SEARCH_DIR ("/ usr / lib");

SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64") SEARCH_DIR("/usr/local/lib64") SEARCH_DIR("/lib64")

SEARCH_DIR ("/ usr / lib64") SEARCH_DIR ("/ usr / x86_64-pc-linux-gnu / lib") SEARCH_DIR ("/ usr / local / lib") SEARCH_DIR ("/ lib")

SEARCH_DIR ("/ usr / lib");

Un sistema de 32 bits puede ver algunos directorios diferentes. Por ejemplo, aquí está el resultado de una máquina i686:

SEARCH_DIR ("/ usr / i686-pc-linux-gnu / lib32") SEARCH_DIR ("/ usr / local / lib32") SEARCH_DIR ("/ lib32")

SEARCH_DIR ("/ usr / lib32") SEARCH_DIR ("/ usr / i686-pc-linux-gnu / lib") SEARCH_DIR ("/ usr / local / lib") SEARCH_DIR ("/ lib")

SEARCH_DIR ("/ usr / lib");

SEARCH_DIR ("/ usr / i686-pc-linux-gnu / lib32") SEARCH_DIR ("/ usr / local / lib32") SEARCH_DIR ("/ lib32")

SEARCH_DIR ("/ usr / lib32") SEARCH_DIR ("/ usr / i686-pc-linux-gnu / lib") SEARCH_DIR ("/ usr / local / lib") SEARCH_DIR ("/ lib")

SEARCH_DIR ("/ usr / lib");

A continuación, asegúrese de que estamos usando la libc correcta:

grep "/lib.*/libc.so.6" dummy.log

La salida del último comando debería ser:

intento de abrir /lib/libc.so.6 exitoso

Por último, asegúrese de que GCC esté utilizando el vinculador dinámico correcto:

grep encontrado dummy.log

La salida del último comando debe ser (teniendo en cuenta las diferencias específicas de la plataforma en el nombre del enlazador dinámico):

encontrado ld-linux-x86-64.so.2 en /lib/ld-linux-x86-64.so.2

Si la salida no aparece como se muestra arriba o no se recibe en absoluto, entonces algo está muy mal. Investigue y vuelva sobre los pasos para averiguar dónde está el problema y corregirlo. La razón más probable es que algo salió mal con el ajuste del archivo de especificaciones. Cualquier problema deberá resolverse antes de continuar con el proceso.

Una vez que todo funcione correctamente, limpie los archivos de prueba:

rm -v dummy.c a.out dummy.log

Finalmente, mueva un archivo extraviado:

mkdir -pv / usr / share / gdb / auto-load / usr / lib

mv -v /usr/lib/*gdb.py / usr / share / gdb / auto-load / usr / lib

mkdir -pv / usr / share / gdb / auto-load / usr / lib

mv -v /usr/lib/*gdb.py / usr / share / gdb / auto-load / usr / lib