Tiempo estimado de construcción: 11.0 SBU Estimación del espacio necesario en disco: 274 MB |
Ahora están instaladas las herramientas necesarias para comprobar GCC y Binutils (Expect, Tcl y DejaGnu). Podemos continuar reconstruyendo GCC y Binutils, enlazandolos con la nueva Glibc, y comprobarlos adecuádamente. Sin embargo, una cosa a tener en cuenta es que estos bancos de pruebas son altamente dependientes del correcto funcionamiento de los pseudoterminales (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" |
Si recibes este mensaje:
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.
Descomprime los tres paquetes de GCC (-core, -g++, y -testsuite) en un mismo directorio de trabajo. Todos ellos se desempaquetarán en un único subdirectorio gcc-3.3.1/.
Primero, corrige un problema y haz un ajuste esencial:
patch -Np1 -i ../gcc-3.3.1-no_fixincludes-2.patch patch -Np1 -i ../gcc-3.3.1-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 que usamos para el sistema LFS.
El último 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.
Importante: Estos parches son críticos para asegurar una correcta construcción. No olvides aplicarlos.
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.1/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:
--enable-threads=posix: Esto activa el manejo de excepciones C++ para codigo multihilo.
--enable-__cxa_atexit: Esta opción permite el uso de __cxa_atexit, en vez de atexit, para registrar destructores C++ para objetos estáticos locales y objetos globales. Es esencial para un manejo de destructores completamente compatible con los estándares. Tambien afecta al ABI de C++ obteniendo librerías compartidas y programas C++ interoperables con otras distribuciones Linux.
--enable-clocale=gnu: Esta opción asegura que se seleccione el modelo de locale correcto para las librerías C++ en todos los casos. Si el guión configure encuentra instalada la locale de_DE, seleccionará el modelo correcto de gnu. Sin embargo, las personas que no instalan la locale de_DE corren el riesgo de construir librerías incompatibles con la ABI debido a que se selecciona el modelo de locale generic que es erróneo.
--enable-languages=c,c++: Esta opción es necesaria para asegurar que se construyan tanto el compilador de C como el de C++.
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.
Nota: Hay que resaltar que ejecutar aquí el banco de pruebas de GCC no se considera tan importante como ejecutarlo en el Capítulo 6.
Comprueba los resultados:
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.1/contrib/test_summary | more |
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.1 en sistemas i686-pc-linux-gnu en http://gcc.gnu.org/ml/gcc-testresults/2003-08/msg01612.html.
Advierte que los resultados contienen:
* 1 XPASS (unexpected pass) for g++ * 1 FAIL (unexpected failure) for g++ * 2 FAIL for gcc * 26 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 26 éxitos inesperados para libstdc++ son consecuencia de usar la opción --enable-clocale=gnu, que es la elección correcta en los sistemas basados en Glibc versiones 2.2.5 y posteriores. El soporte subyacente a los 'locale' en la librería de C de GNU es superior al modelo "genérico" elegido por defecto (que puede ser aplicable si estuvieras usando Newlibc, Sun-libc u otra libc). El conjunto de pruebas para libstdc++ parece esperar encontrar el modelo "genérico", por lo tanto no se asume que las puebas siempre tendrán éxito.
Los fallos inesperados con frecuencia pueden ignorarse. Los desarrolladores de GCC normalmente los tienen en cuenta pero todavía no se han puesto a corregirlos. 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 la sección "Bloquear" Glibc y repite la prueba. Si los resultados son malos muy posiblemente se deba a que olvidaste aplicar el parche Specs de GCC mencionado arriba.