5.11. GCC-3.4.3 - Fase 2

Se sabe que este programa se comporta mal si se cambian sus parámetros de optimización (incluyendo las opciones -march y -mcpu). Si tienes definida cualquier variable de entorno que altere las optimizaciones por defecto, como CFLAGS o CXXFLAGS, desactívala cuando construyas GCC.

Ahora están instaladas las herramientas necesarias para comprobar GCC y Binutils: Tcl, Expect y DejaGNU. Por lo que ahora pueden reconstruirse GCC y Binutils enlazándolos con la nueva Glibc y comprobarlos adecuadamente (si llevas a cabo los bancos de pruebas en este capítulo). Sin embargo, una cosa a tener en cuenta es que estos bancos de pruebas son altamente dependientes del correcto funcionamiento de las pseudo-terminales (PTYs) suministradas por tu distribución anfitrión. Las PTYs se implementan normalmente mediante el sistema de ficheros devpts. Comprueba si tu sistema anfitrión está configurado correctamente en este aspecto ejecutando una simple prueba:

expect -c "spawn ls"

La respuesta podría ser:

The system has no more ptys.
Ask your system administrator to create more.

El sistema no tiene más ptys.
Pídele al administrador del sistema que cree más.

Si recibes el mensaje anterior, tu sistema anfitrión no está configurado para operar correctamente con PTYs. En este caso no hay razón para ejecutar los bancos de pruebas de GCC y Binutils hasta resolver este asunto. Puedes consultar la FAQ de LFS en http://www.linuxfromscratch.org/faq//lfs/faq.html#no-ptys para obtener información sobre cómo conseguir que funcionen las PTYs.

Corrige un problema conocido y haz un ajuste esencial:

patch -Np1 -i ../gcc-3.4.3-no_fixincludes-1.patch
patch -Np1 -i ../gcc-3.4.3-specs-2.patch

El primer parche desactiva el guión fixincludes de GCC. Antes lo mencionamos brevemente, pero ahora queremos brindarte una explicación un poco más profunda del proceso de corrección de las cabeceras que realiza dicho guión. En circunstancias normales, el guión fixincludes de GCC busca en tu sistema los ficheros de cabecera que necesita corregir. Puede encontrar que algún fichero de cabecera de Glibc de tu sistema anfitrión necesite ser corregido, en cuyo caso lo corrige y lo pone en un directorio privado de GCC. Más adelante, en el Capítulo 6, después de instalar la nueva Glibc, se buscará en el directorio privado antes que en el directorio del sistema, por lo que GCC encontrará las cabeceras corregidas del sistema anfitrión, que muy probablemente no se corresponderán con la versión de Glibc utilizada para el sistema LFS.

El segundo parche cambia la localización por defecto para GCC del enlazador dinámico (normalmente ld-linux.so.2). También elimina /usr/include de la ruta de búsqueda de GCC. Parchear ahora en lugar de ajustar el fichero specs tras la instalación asegura que nuestro nuevo enlazador dinámico sea utilizado durante la construcción actual de GCC. Esto es, todos los binarios finales (y temporales) creados durante la construcción se enlazarán contra la nueva Glibc.

Vuelve a crear un directorio de construcción dedicado:

mkdir ../gcc-build
cd ../gcc-build

Prepara GCC para su compilación:

../gcc-3.4.3/configure --prefix=/tools \
    --libexecdir=/tools/lib --with-local-prefix=/tools \
    --enable-clocale=gnu --enable-shared \
    --enable-threads=posix --enable-__cxa_atexit \
    --enable-languages=c,c++ --disable-libstdcxx-pch

Significado de las nuevas opciones de configure:

Compila el paquete:

make

Aquí no hace falta usar el objetivo bootstrap, ya que el compilador que estamos utilizando para construir GCC ha sido construido a partir de la misma versión de las fuentes de GCC que usamos antes.

La compilación está completa. Como se mencionó antes, no es obligatorio ejecutar los bancos de pruebas de las herramientas temporales en este capítulo. Si de todas formas deseas ejecutar el banco de pruebas de GCC, hazlo con el siguiente comando:

make -k check

La opción -k se usa para que el banco de pruebas se ejecute por completo y sin detenerse ante el primer error. El banco de pruebas de GCC es muy exhaustivo y es casi seguro que generará algunos fallos. Para ver un resumen de los resultados ejecuta:

../gcc-3.4.3/contrib/test_summary

Para ver sólo el resumen, redirige la salida a través de grep -A7 Summ.

Puedes comparar tus resultados con los que se encuentran en http://www.linuxfromscratch.org/lfs/build-logs/6.1/.

No siempre se pueden evitar unos cuantos fallos inesperados. Los desarrolladores de GCC normalmente están al tanto de dichos problemas, pero no los han resulelto aún. A no ser que tus resultados difieran en gran medida de los mostrados en la anterior URL, es seguro continuar.

Instala el paquete:

make install

En este punto se recomienda encarecidamente que se repitan las comprobaciones que realizamos anteriormente en este capítulo. Regresa a la Sección 5.7, “Ajustar las herramientas”, y repite la pequeña prueba de compilación. Si los resultados son malos muy posiblemente se deba a que no se aplicó correctamente el parche Specs de GCC.