GCC-3.3.3 - Fase 2

Tiempo estimado de construcción:  11.0 SBU
Espacio requerido en disco:       332.7 MB

Ahora están instaladas las herramientas necesarias para comprobar GCC y Binutils: Tcl, Expect y DejaGnu. Por tanto ahora podemos reconstruir 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 los pseudo-terminales (PTYs) suministrados por tu distribución anfitrión. Hoy en día, los PTYs se implementan normalmente mediante el sistema de ficheros devpts. Puedes comprobar rápidamente si tu sistema anfitrión está configurado correctamente en este aspecto ejecutando una simple prueba:

expect -c "spawn ls"

La respuesta podría ser:

Si recibes el mensaje anterior, tu sistema anfitrión no está configurado para operar correctamente con PTY. En este caso no hay razón para ejecutar los bancos de pruebas de GCC y Binutils hasta que seas capaz de resolver este asunto. Puedes consultar el Wiki de LFS en http://wiki.linuxfromscratch.org/ para obtener información sobre cómo conseguir que funcionen los PTYs.

Esta vez construiremos los compiladores C y C++, por lo que tendrás que desempaquetar los paquetes core y g++ (y también testsuite si quieres ejecutar las pruebas). Desempaquetándolos en tu directorio de trabajo todos ellos se desempaquetarán en un único subdirectorio gcc-3.3.3/.

Primero, corrige un problema y haz un ajuste esencial:

patch -Np1 -i ../gcc-3.3.3-no_fixincludes-1.patch
patch -Np1 -i ../gcc-3.3.3-specs-1.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 que usamos 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 de especificaciones 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 aparte:

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

Antes de comenzar con la construcción de GCC, recuerda desactivar cualquier variable de entorno que modifique las opciones de optimización por defecto.

Ahora, prepara GCC para su compilación:

../gcc-3.3.3/configure --prefix=/tools \
    --with-local-prefix=/tools \
    --enable-clocale=gnu --enable-shared \
    --enable-threads=posix --enable-__cxa_atexit \
    --enable-languages=c,c++

El 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 recomendamos 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 conjunto de pruebas se ejecute por completo y sin detenerse ante el primer error. El conjunto 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.3.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 publicados en la lista de correo gcc-testresults para configuraciones similares a la tuya. Hay un ejemplo de cómo debería comportarse GCC-3.3.3 en sistemas i686-pc-linux-gnu en http://gcc.gnu.org/ml/gcc-testresults/2004-01/msg00826.html.

Advierte que los resultados contienen:

* 1 XPASS (unexpected pass) for g++
* 1 FAIL (unexpected failure) for g++
* 24 XPASS's for libstdc++

El éxito inesperado (unexpected pass) de g++ se debe al uso de la opción --enable-__cxa_atexit. Aparentemente, no todas las plataformas soportadas por GCC tienen soporte para “__cxa_atexit” en sus librerías de C, así que no siempre se espera pasar esta prueba con éxito.

Los 24 éxitos inesperados para libstdc++ son consecuencia de usar la opción --enable-clocale=gnu. Esta opción, que es la elección correcta en los sistemas basados en Glibc versiones 2.2.5 y posteriores activa en la librería C de GNU un soporte de locale que es superior al modelo por defecto generic (que puede ser aplicable si estuvieras usando Newlibc, Sun-libc u otra libc). El conjunto de pruebas para libstdc++ parece esperar el modelo generic, de aquí que no siempre se espere pasar estas pruebas.

Si tienes unos pocos fallos inexperados con frecuencia puedes ignorarlos. Los desarrolladores de GCC normalmente los tienen en cuenta pero todavía no se han puesto a corregirlos. Un caso particular es la prueba de filebuf_members en el banco de pruebas de la librería estándar C++. Se ha observado que esta prueba falla en ciertos casos, pero se supera en otros. En resumen, a menos que tus resultados difieran mucho de los mostrados en la anterior URL, es seguro continuar adelante.

Finalmente, 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 “Ajustar las herramientas” y repite la pequeña prueba de compilación. Si los resultados son malos muy posiblemente se deba a que olvidaste aplicar el parche Specs de GCC mencionado arriba.

Los detalles sobre este paquete se encuentran en “Contenido de GCC”.