# [PORTAGE] stage1/toolchain (cerrado)

## the incredible hurd

Quiero en una de las máquinas i686 añadir las CFLAGS -mregparm=2 y -msseregparm para ver si aportan una mejora importante o no.

¿En qué consiste exactamente el o la toolchain? Pensaba que con hacer un emerge -e system en esa máquina bastaría. Pero al añadir dichas CFLAGS ocurren bastantes errores.

Por supuesto que he leído los warnings del man de gcc.

¿Alguien con experiencia en Stage1 me puede ayudar? (Siempre he usado los Stage3).

¿Cuál sería el orden? ¿Primero gcc o glibc? Supongo que glibc, gcc y de nuevo glibc. Pero necesitaría la ayuda de alguien con más experiencia.

----------

## ackward

Del faq http://www.gentoo.org/doc/en/faq.xml#stage12

Lo que no tengo claro es si en el bootstrap vas a poder poner esos parametros ya que no es su objetivo, sino tener un toolchain valido y en general es bastante minimo. Por ese motivo, tampoco necesitarias intentar hacer un bootstrap, mientras tengas los compiladores y libererias bien, modificando las flags y un "emerge -e system" deberia ser suficiente incluso con un stage3 o mas paquetes

 *Quote:*   

> 
> 
> How do I Install Gentoo Using a Stage1 or Stage2 Tarball?
> 
> The Gentoo Handbook only describes a Gentoo installation using a stage3 tarball. However, Gentoo still provides stage1 and stage2 tarballs. This is for development purposes (the Release Engineering team starts from a stage1 tarball to obtain a stage3) but shouldn't be used by users: a stage3 tarball can very well be used to bootstrap the system. You do need a working Internet connection.
> ...

 

----------

## i92guboj

 *the incredible hurd wrote:*   

> 
> 
> ¿En qué consiste exactamente el o la toolchain?
> 
> 

 

Eso depende de a quién le preguntes. Una toolchain es un conjunto de utilidades que se usan secuencialmente para obtener un resultado. Cuando hablamos de la toolchain gnu normalmente estamos refiriéndonos al conjunto de utilidades y programas necesarios para producir un programa ejecutable. La definición es un poco borrosa, pero normalmente incluye al compilador, binutils, y algunas utilidades relacionadas con todo el proceso como make, libtool o las autotools en general.

 *Quote:*   

> 
> 
> Pensaba que con hacer un emerge -e system en esa máquina bastaría. Pero al añadir dichas CFLAGS ocurren bastantes errores.
> 
> Por supuesto que he leído los warnings del man de gcc.
> ...

 

Al margen de los warnings en man, estas opciones no son muy usadas, y no están testeadas en absoluto, por lo cual no podemos descartar que sean simplemente defectuosas, o que no anden muy finas en determinadas configuraciones. No puedo ayudarte con dichas opciones, sorry.

 *Quote:*   

> 
> 
> ¿Alguien con experiencia en Stage1 me puede ayudar? (Siempre he usado los Stage3).
> 
> 

 

En principio usar un stage1 se varía poco de un stage3. Tan solo es cuestión de hacer el bootstrap usando el script en /usr/portage/scripts/bootstrap.sh. Hace años que no uso un stage1 y no recuerdo nada más. Excepto por el tiempo desperdiciado, no había más diferencia con el stage3.

 *Quote:*   

> ¿Cuál sería el orden? ¿Primero gcc o glibc? Supongo que glibc, gcc y de nuevo glibc. Pero necesitaría la ayuda de alguien con más experiencia.

 

Supongo que lo mejor sería compilar gcc primero, y luego glibc para tenerla "optimizada" con el compilador más reciente. Luego puedes recompilar gcc si así lo deseas, y todo lo demás que quieras. La salida que produce gcc no depende de como fue compilado, sino de la versión de gcc de que se trate. En otras palabras: gcc 4.2 siempre debería producir la misma salida, siempre que los flags sean los mismos. Independientemente de como se haya compilado gcc.

Quedaría así: gcc, glibc, y luego todo lo que quieras (incluyendo posiblemente a gcc de nuevo si así lo deseas).

----------

## gringo

 *Quote:*   

> ¿Alguien con experiencia en Stage1 me puede ayudar? (Siempre he usado los Stage3)

 

yo hace años que no uso un stage1, porque tampoco lo veo mucho sentido, así que me limito a decirte como lo hago yo.

Si añado / quito flags, para recompilarlo todo yo hago lo siguiente ( lo que no quiere decir que sea lo correcto ) :

en caso de que implique una actualización de gcc :

emerge -av gcc

( selecciono el nuevo compilador si hiciera falta)

emerge -av binutils gcc linux-headers glibc libtool

emerge -eav world

sino :

emerge -av binutils gcc linux-headers glibc libtool

emerge -eav world

Esto mismo lo he hecho hace dos semanas cuando he actualizado a gcc-4.3 ya que añadí unos flags para juguetear y para hacer pruebas.

Hasta hora siempre me ha funcionado bastante bien.

A ver si te sirve de algo ...

saluetes

----------

## the incredible hurd

Gracias ackward, quizá no me expresé con suficiente claridad, pretendía hacer una especie de stage1 desde un stage3, dado que emerge -e system falla miserablemente, porque no empieza reconstruyendo la toolchain, sino que empieza con otros paquetes y eso produce errores con esas CFLAGS en cuestión, porque es necesario tener la toolchain limpia con esas CFLAGS incluídas previamente, para poder compilar todos los siguientes paquetes que haga falta.

No acierto a adivinar por qué emerge -e system no comienza recompilando toda la toolchain; pero siguiendo las amables indicaciones de i92guboj y las muy útiles indicaciones de gringo... con un emerge -evp system gcc ocupa el lugar 322, glibc el 332, binutils el 73, linux-headers el 32 y libtool el 68, al menos en el caso de esa máquina.

¿Qué determina el orden de los paquetes en system?

No tengo la menor idea, sólo sé que añadir esas CFLAGS y no comenzar recompilando toda la toolchain causa muchos errores y muy dispares si se prosigue con emerge --resume --skipfirst, aunque muy lógicos por otra parte, si se leen los warnings del man de gcc.

 *i92guboj wrote:*   

> 
> 
> Al margen de los warnings en man, estas opciones no son muy usadas, y no están testeadas en absoluto, por lo cual no podemos descartar que sean simplemente defectuosas, o que no anden muy finas en determinadas configuraciones. No puedo ayudarte con dichas opciones, sorry.
> 
> 

 

Esa era mi intención precisamente, testearlas, comprobar su funcionamiento. Si se usa la búsqueda en el foro, el lugar más común en el que aparece mregparm es en los nvidia-drivers y lo ponen como 3.

Todo surgió de  *Linux Assembly HOWTO wrote:*   

> To optimize even more, option −mregparm=2 and/or corresponding function attribute might help, but might pose lots of problems when linking to foreign code, including libc. There are ways to correctly declare foreign functions so the right call sequences be generated, or you might want to recompile the foreign libraries to use the same register−based calling convention...

 

O para enlazar directamente, aunque hay que leer algo más:

http://tldp.org/HOWTO/Assembly-HOWTO/gcc.html

Es realmente problemática tal y como se advierte por todas partes, quizá por eso me apetecía jugar con ella, lo vi como un reto y gentoo es la mejor herramienta que conozco para ese desafío. Porque además debería proporcionar un mayor rendimiento dado que se usan registros para pasar argumentos y de lo contrario no se usa ningún registro.

En cuanto termine la máquina de compilar la actualización de openoffice, para calentar motores   :Twisted Evil:   copia de seguridad y seguiré las instrucciones de gringo para ver qué ocurre

----------

## gringo

 *Quote:*   

> ... con un emerge -evp system gcc ocupa el lugar 322, glibc el 332, binutils el 73, linux-headers el 32 y libtool el 68, al menos en el caso de esa máquina.
> 
> ¿Qué determina el orden de los paquetes en system?
> 
> No tengo la menor idea, sólo sé que añadir esas CFLAGS y no comenzar recompilando toda la toolchain causa muchos errores y muy dispares si se prosigue con emerge --resume --skipfirst, aunque muy lógicos por otra parte, si se leen los warnings del man de gcc. 

 

no tengo ni idea tampoco de porque portage lo hace así, pero si estaría bien tener alguna herramienta oficial que (re)compilara el toolchain adecuadamente ( y el resto del sistema si es necesario). No digo tampoco que lo haga de forma totalmente automatizada pero si que diera instrucciones de como hacerlo o algo similar.

Hay un par de scripts pululando por los foros ( emwrap, update) que (entre otras cosas) hacen mas o menos lo que yo hago cuando quiero actualizar el toolchain / sistema.

saluetes

----------

## i92guboj

 *the incredible hurd wrote:*   

> 
> 
> ¿Qué determina el orden de los paquetes en system?
> 
> No tengo la menor idea, sólo sé que añadir esas CFLAGS y no comenzar recompilando toda la toolchain causa muchos errores y muy dispares si se prosigue con emerge --resume --skipfirst, aunque muy lógicos por otra parte, si se leen los warnings del man de gcc.
> ...

 

Pues supongo que, en primera instancia, el grafo de dependencias. Y a partir de ahí, no tengo ni idea.

 *Quote:*   

>  *i92guboj wrote:*   
> 
> Al margen de los warnings en man, estas opciones no son muy usadas, y no están testeadas en absoluto, por lo cual no podemos descartar que sean simplemente defectuosas, o que no anden muy finas en determinadas configuraciones. No puedo ayudarte con dichas opciones, sorry.
> 
>  
> ...

 

Comprendo. El principal problema que le veo es, concretamente, hasta donde llega la necesidad de compilar el resto del código usando los mismos parámetros. Lo digo porque:

A. El kernel pasa de flags, a no ser que cambies los makefiles tú mismo. Lo comento porque si compilas drivers externos con dichos flags, puede que no sepan enlazar con tu kernel.

B. Algunos paquetes filtras las CFLAGS más sospechosas, o simplemente las resetean a cero. Vigila esto, porque si algún paquete no compila puede que sea simplemente porque alguna dependencia filtró los flags y no se compiló con el soporte adecuado.

----------

## esculapio

Hay un script llamado emwrap dando vueltas por los foros que tuvo sucesivas modificaciones, que sirve para recontruir el toolchain, yo hace años que no lo uso y hay varios de la opinión que no sirve el esfuerzo de recompilar, muchos paquetes hay que hacerlo dos veces para estar seguros. El script te automatiza el proceso, por las dudas empaqueta todo, el toolchain por ahi no da problemas, sino una multitud de paquetes que vienen despues.

----------

## the incredible hurd

 *gringo wrote:*   

> no tengo ni idea tampoco de porque portage lo hace así, pero si estaría bien tener alguna herramienta oficial que (re)compilara el toolchain adecuadamente ( y el resto del sistema si es necesario). No digo tampoco que lo haga de forma totalmente automatizada pero si que diera instrucciones de como hacerlo o algo similar.

 

```
emerge -e toolchain
```

 sería perfecto, ¿dónde se hacen las feature requests? Lo veo muy necesario, a partir de este problema.

El único problema es que el toolchain es distinto para cada arquitectura, pero basándose en las keywords de make.conf asunto resuelto.

 *i92guboj wrote:*   

> 
> 
> A. El kernel pasa de flags, a no ser que cambies los makefiles tú mismo. Lo comento porque si compilas drivers externos con dichos flags, puede que no sepan enlazar con tu kernel.
> 
> B. Algunos paquetes filtras las CFLAGS más sospechosas, o simplemente las resetean a cero. Vigila esto, porque si algún paquete no compila puede que sea simplemente porque alguna dependencia filtró los flags y no se compiló con el soporte adecuado.
> ...

 

Con respecto a A. busca en el foro mregparm, aparece sobre todo cuando se compilan los nvidia-drivers. Por lo que de momento me permitiré ponerlo en duda. Por otra parte no sería la primera vez que juego con los makefiles del kernel, aunque no me haga mucha gracia, también me he leído sus warnings   :Wink: 

Con respecto a B.

```

$ grep mregparm /usr/portage/*/*/*.ebuild

$

```

Si las cosas no se tuercen, mañana miércoles empiezo a reconstruir la toolchain y espero poder cerrar este hilo, ya sea con buenos o malos resultados... Desde luego de ser buenos voy a tardar más de lo que cabría esperar.

----------

## gringo

 *Quote:*   

> emerge -e toolchain

 

ahora que me doy cuenta, en las próximas versiones de portage ( la 2.2. , hardmasked ahora mismo) habrá la posibilidad de especificar tu propia "selección de paquetes" ( sets en inglés - como el world o el system que tenemos ahora), así que si entiendo bien como lo quieren hacer y siguiendo tu ejemplo, sería tan fácil como crear un set que contenga los paquetes del toolchain y simplemente ejecutar algo en plan  :

emerge -e @toolchain

emerge -e world 

o algo similar vaya.

Esto creo que ya se puede hacer con paludis o pkgcore ( de pkgcore no estoy seguro pero paludis soporta sets); con paludis incluso debería ser relativamente sencillo instruir al gestor de paquetes a través de sus múltiples hooks que si p.ej. se detecta una nueva versión del compilador en los paquetes a actualizar que suponga un cambio de versión importante, se alerte de ello al usuario y se de la opción de abortar la actualización y/o lanzar una recompilación del sistema una vez actualizado. Pero esto sólo son pajas mentales mías, seguramente sea mas complejo que eso ... el script update que enlacé mas arriba creo una de las cosas que hace es esto mismo, pero hablo de lo que leo, no lo he probao.

 *Quote:*   

> sería perfecto, ¿dónde se hacen las feature requests? Lo veo muy necesario, a partir de este problema. 

 

imagino que bugzilla o ponerse en contacto con los devs de portage sería lo suyo, aunque me extrañaría que esta fuera la primera vez que se les plantea esta situación. 

En cuanto a lo que te comenta i92guboj mas arriba, yo nunca he tenido problemas con módulos compilados con flags distintas del kernel ( que no quiere decir que no sea cierto o que no pueda pasar), pero si si se compilan con versiones del compilador distintas a la del kernel si se tiene activado la opción ver_magic ( hablo de memoria, pero algo así es), pero esto ya lo sabréis. 

Para el filtrado de flags en portage, se usa la eclass flag-o-matic, por si te sirve para algo.

saluetes

----------

## i92guboj

 *gringo wrote:*   

>  *Quote:*   emerge -e toolchain 
> 
> ahora que me doy cuenta, en las próximas versiones de portage ( la 2.2. , hardmasked ahora mismo) habrá la posibilidad de especificar tu propia "selección de paquetes" ( sets en inglés - como el world o el system que tenemos ahora), así que si entiendo bien como lo quieren hacer y siguiendo tu ejemplo, sería tan fácil como crear un set que contenga los paquetes del toolchain y simplemente ejecutar algo en plan  :
> 
> emerge -e @toolchain
> ...

 

Hasta cierto punto, esto se puede emular de forma bastante precaria usando meta-ebuilds. Sin embargo, portage por ahora no es capaz de emerger todos los paquetes integrados en un meta. Lo más cercano que se puede hacer es usar -e para emerger todas las dependencias hasta las más lejanas.

 *Quote:*   

> En cuanto a lo que te comenta i92guboj mas arriba, yo nunca he tenido problemas con módulos compilados con flags distintas del kernel

 

Por lo general no hay por qué tenerlos. Es la propia naturaleza de dicho flag lo que la hace problemática.

 *gcc man page wrote:*   

> 
> 
>        -mregparm=num
> 
>            Control how many registers are used to pass integer arguments.  By default, no
> ...

 

No tengo experiencia con este flag, pero tal y como yo lo entiendo, si distintas piezas de código enlazan de forma dinámica, y se ha usado dicho flag en una de ellas, habrá que compilar todas las piezas con el mismo flag porque si no se producirán incompatibilidades. Y en este caso, los módulos enlazan dinámicamente con el kernel, y por tanto dicha advertencia es apllicable.

Esto puede ser un problema particularmente molesto en módulos de fuente cerrada, si llega a producirse alguna incompatibilidad, porque en dicho caso no hay posibilidad alguna de recompilar.

----------

## the incredible hurd

No ha sido posible, ni cambiando el orden de los cinco paquetes que menciona gringo.

safe-cflags al canto.

----------

