# [gcc] - Actualizar gcc de forma segura (abierto)

## papu

Mod Edit (i92guboj): Separado desde el esto hilo:

tras cambio de placa base, el cd de gentoo no es booteable

 *i92guboj wrote:*   

>  *papu wrote:*    *i92guboj wrote:*   Yo también he tenido problemas al activar al mismo tiempo drivers IDE y SATA. Lo que hago normalmente es dejar solo el soporte SATA, y dejar que mis discos IDE se manejen por emulación. En cuanto al cdrom, simplemente añado esto a mi línea del kernel, y funciona sin problemas:
> 
> ```
> 
> atapi_enabled=1
> ...

 

he usado kubuntu instalado desde windows se instala en un momento y es mucho mas rapido que una knopix en 10 min tienes un linux totalmente operativo , pero me refiero que el grub en ese caso va bien, no se porque desde gentoo,  solo sale  GRUB> para que tenga que decirle yo manualmente lo que ya tiene configurado el mismo, eso es lo que no logro entender.  Configurando el kernel a mano como siempre hago  , el cual he  de pulir, me detecta todo lo que quiero y quito todo lo que no necesito.  El problema me lo da con el dichoso arranque grrrr, primero el cd live de gentoo no lo detecta y luego ahora el grub tontea, grrrr.

Eso si puedo asegurar que gentoo64 en mi pc nuevo virtualmente VUELA, aunque le queda bastante para tener un sistema bien puesto ahora mismo.

Tengo una duda compile el gcc 4.2.3 y ahora tengo 2 versiones de gcc esta y la que ya tenia por defecto.  Pero yo quiero usar la nueva, entonces simplmente emerge -C gcc(la que no quiero) luego ya el mismo usara la nueva ? o es mas complicado que eso,  he mirado  gcc-config pero no veo claro el tema este y prefiero no hacer -C antes de que pueda pasar algo.

saludos, adéu.

----------

## i92guboj

Para listar los compiladores disponibles:

```
gcc-config -l
```

Para escoger uno:

```
gcc-config <número>
```

En principio, puedes eliminar las versiones anteriores sin problema. No es estrictamente necesario recompilar nada más, pero si puedes, recompila el kernel con el nuevo compilador. Lo del kernel es porque, si tienes módulos externos (por ejemplo, drivers de video), dejarán de funcionar en cuanto los actualices o los recompiles con el nuevo gcc (el kernel de linux no carga módulos que no hayan sido compilados con la misma versión exacta de compilador usada para compilar el mismo kernel).

Por lo demás, no creo que tengas problemas, siempre que no instales ninguna versión beta o alpha de gcc.

Esto es la regla general, de todas formas, hay documentación oficial sobre el tema, échale un vistazo, y haz caso de lo que diga allí:

http://www.gentoo.org/doc/en/gcc-upgrading.xml

Saludos.

----------

## papu

 *i92guboj wrote:*   

> Para listar los compiladores disponibles:
> 
> ```
> gcc-config -l
> ```
> ...

 

simplemente haciendo lo que dices de gcc-config devería funcionar verdad?  o incluso solo con emerge -C ?

yo no recuerdo haber hecho nunca tantas cosas para activar gcc, simplmente borraba el anterior , aunque no recuerdo si lo hacia yo manualmente o lo hacia el emerge tras emerger un nuevo gcc( es lo que no recuerdo) . Lo del kernel tiene su logica y lo tendre en cuenta.

Siempre he usado paquetes inestables y jamas he tenido problemas, si me da problema algun paquete lo bloqueo y uso el que vaya bien.

con lo bien que me iba gentoo antes de mi canvio de placa ahora todo da problemas.

saludos adéu.

----------

## i92guboj

 *papu wrote:*   

> 
> 
> simplemente haciendo lo que dices de gcc-config devería funcionar verdad?  o incluso solo con emerge -C ?
> 
> 

 

Primero, usa gcc-config, y tras cambiar de compilador, vuelve a usar "gcc-config -l" para estar seguro de que el compilador seleccionado es el más actual. Hasta donde yo se, esto tienes que hacerlo a mano desde siempre. (Hubo un tiempo que se podía hacer con eselect también).

Solamente tras asegurarte de que tu compilador seleccionado es el correcto, podrás eliminar los demás sin crear problemas posteriormente.

 *Quote:*   

> 
> 
> Siempre he usado paquetes inestables y jamas he tenido problemas, si me da problema algun paquete lo bloqueo y uso el que vaya bien.
> 
> con lo bien que me iba gentoo antes de mi canvio de placa ahora todo da problemas.
> ...

 

Inestable como en ~x86 o ~amd64 es algo admisible, los paquetes alpha para gcc y glibc jamás entran en dichas ramas inestables. Éstos, en lugar de eso, se marcan como hard masked, y tienes que desenmascararlos a mano para poder instalarlos, con la garantía casi total de romper tu sistema de forma segura. Tan solo se deben usar si tienes intención de reportar bugs o contribuir con parches.

----------

## papu

 *i92guboj wrote:*   

>  *papu wrote:*   
> 
> simplemente haciendo lo que dices de gcc-config devería funcionar verdad?  o incluso solo con emerge -C ?
> 
>  
> ...

 

si me refiero a que uso los ~, entonces eso escojo el gcc nuevo y luego emerge -C con el anterior y compilo kernel otra vez con el nuevo verdad? de hecho tengo que compilar ya que he de configurar mejor el kernel.  LO que yo hago es quitar los headers que vienen por defecto asi no me los pide otra vez porque compilando el kernel ya tengo todo lo necesario. ¿ es correcto?

saludos, adéu.

----------

## i92guboj

 *papu wrote:*   

> 
> 
> si me refiero a que uso los ~, entonces eso escojo el gcc nuevo y luego emerge -C con el anterior y compilo kernel otra vez con el nuevo verdad? de hecho tengo que compilar ya que he de configurar mejor el kernel.

 

Suena bien.

 *Quote:*   

> LO que yo hago es quitar los headers que vienen por defecto asi no me los pide otra vez porque compilando el kernel ya tengo todo lo necesario. ¿ es correcto?
> 
> saludos, adéu.

 

¿A qué header te refieres? Si estás hablando de sys-kernel/linux-headers, es algo completamente independiente del kernel, y los necesitas tengas el kernel que tengas. Compilar programas de usuario contra las cabeceras del kernel en lugar de los linux-headers no es una buena idea.

----------

## papu

 *i92guboj wrote:*   

>  *papu wrote:*   
> 
> si me refiero a que uso los ~, entonces eso escojo el gcc nuevo y luego emerge -C con el anterior y compilo kernel otra vez con el nuevo verdad? de hecho tengo que compilar ya que he de configurar mejor el kernel. 
> 
> Suena bien.
> ...

 

a vaya pues los metere otra vez y porque no es buena idea? yo crei que era correcto no se , no me ha dado problemas tampoco  :Smile: 

y siempre que compilo un kernel nuevo recomendable meter los headers de ese kernel o puedo seguir usando las anteriores.

YO crei que al compilar un kernel ya pues tenias los headers ahi disponibles o algo asi y no era necesario los headers, a veces lo he comentado con gente y me han dicho que mientras tubiera los compilados del kernel pues no había problema   :Smile: 

ups no me di cuenta que habías creado otro hilo  :Smile: 

saludos, adéu.

----------

## i92guboj

 *papu wrote:*   

> 
> 
> a vaya pues los metere otra vez y porque no es buena idea? yo crei que era correcto no se , no me ha dado problemas tampoco 
> 
> y siempre que compilo un kernel nuevo recomendable meter los headers de ese kernel o puedo seguir usando las anteriores.
> ...

 

Los .h del kernel cambian muchísimo de una versión a otra, y las aplicaciones de usuario que requieren saber algo del kernel tan solo necesitan conocer algunos detalles. Los headers contenidos en linux-headers son unas cabeceras "mas estables", como un subset del kernel, con todo lo que necesitan las aplicaciones de usuario.

 *Quote:*   

> 
> 
> YO crei que al compilar un kernel ya pues tenias los headers ahi disponibles o algo asi y no era necesario los headers, a veces lo he comentado con gente y me han dicho que mientras tubiera los compilados del kernel pues no había problema  
> 
> 

 

Son raras las aplicaciones que necesitan linux-headers, pero, para empezar, ni siquiera deberías estar preocupándote de eso, porque en Gentoo, si una aplicación necesita algo, lo instala como dependencia. En otras palabras, olvídate de linux headers. Si un programa las instala, es porque las necesita, si no, no hay razón para que las tengas en tu sistema.

Tampoco te preocupes porque su versión no esté sincronizada con la de tu kernel, eso es normal, y no es nada que deba alarmarte.

----------

## papu

 *i92guboj wrote:*   

>  *papu wrote:*   
> 
> a vaya pues los metere otra vez y porque no es buena idea? yo crei que era correcto no se , no me ha dado problemas tampoco 
> 
> y siempre que compilo un kernel nuevo recomendable meter los headers de ese kernel o puedo seguir usando las anteriores.
> ...

 

Bien entonces acabo de meterlas otra vez, y he compilado el glibc ( como ponía al final de los headers o almenos entendí eso).

Ya he cambiado el gcc  es facil no hace falta quitar el otro  gcc-config N(numero kernel)  y ya esta luego  sources /etc/profile y ya puedes usarlo al momento.

en el nuevo gcc hay unas opciones que me han liado , de hecho me siempre lo han hecho, yo siempre he usado la opción -march, la -ntune no la entiendo es decir o no entiendo ninguna de las dos. Este es mi make.conf y se puede ver la configuración actual.  En la info del man gcc 4.2.3  se puede apreciar que la opción -ntune tiene  dos opciones nuevas:generic y native.

Mi pregunta sería entonces que devo poner para tener mejor optimizado: 

-ntune=nocona  -march=nocona

-ntune=native    -march=native

-ntune=native    -march=nocona  

-ntune=native 

-march=nocona  (yo siempre he usado esta opció sin -ntune)

...

...

¿Que diferencia hay entre ellos?  

¿basta solo con uno? 

¿en el caso de que sea uno cual de los dos?

espero haberme explicado

Esto complementa la info del enlace del gcc que he puesto arriba.

```

New Targets and Target Specific Improvements

IA-32/x86-64

    * -mtune=generic can now be used to generate code running well on common x86 chips. This includes AMD Athlon, AMD Opteron, Intel Pentium-M, Intel Pentium 4 and Intel Core 2.

    * -mtune=native and -march=native will produce code optimized for the host architecture as detected using the cpuid instruction.

    * Added a new command-line option -fstackrealign and and __attribute__ ((force_align_arg_pointer)) to realign the stack at runtime. This allows functions compiled with a vector-aligned stack to be invoked from legacy objects that keep only word-alignment.
```

saludos, adéu.

----------

## ekz

Leyendo el enlace que pones, solo puedo citarlo:

 *Quote:*   

>        -march=cpu-type
> 
>            Generate instructions for the machine type cpu-type.  The choices for cpu-type are the same as for -mtune.  More
> 
>            over, specifying -march=cpu-type implies -mtune=cpu-type.

 

Saludos

----------

## i92guboj

 *papu wrote:*   

> 
> 
> en el nuevo gcc hay unas opciones que me han liado , de hecho me siempre lo han hecho, yo siempre he usado la opción -march, la -ntune no la entiendo es decir o no entiendo ninguna de las dos. Este es mi make.conf y se puede ver la configuración actual.  En la info del man gcc 4.2.3  se puede apreciar que la opción -ntune tiene  dos opciones nuevas:generic y native.
> 
> Mi pregunta sería entonces que devo poner para tener mejor optimizado: 
> ...

 

Asumo que quieres decir "-mtune", no "-ntune".

Si es así, entonces la diferencia entre ambas banderas es sutil, pero muy importante: -mtune, por si sola, optimiza para el procesador escogido (o para el detectado, si usas native). Pero, y aquí está la diferencia, -mtune jamás genera código que no pueda correr en la arquitectura base (i386 o x86_64, según el caso).

Es decir, -mtune=nocona, optimiza para nocona, pero jamás va a generar código que sea específico de dicho procesador. Lo cual quiere decir que el código se ejecutará mejor en un nocona, pero aún podrás usarlo en un sempron o un X2, por ejemplo.

-march, por contra, optimiza para el procesador elegido (o el detectado, si usas native), pero usando todo el rango de instrucciones de dicha cpu. Lo cual quiere decir que todo el código generado será incompatible con cualquier otro tipo de cpu que no tenga todo el susodicho juego de instrucciones, al menos.

Desde el punto de vista práctico, en una máquina de escritorio, y si no piensas clonar tu instalación a máquinas distintas con distinta arquitectura, o no vas a servir tus paquetes binarios en LAN o algo así, entonces simplemente usa -march, y ya está.

Si vas a compartir paquetes, puede ser interesante usar -mtune en su lugar. Por ejemplo, si todas tus máquinas con compatibles con i386, entonces usarías -mtune=prescott, así el código andarían en tu pentium4 (en 32 bits), pero podrías ejecutarlos en un pentium II o un athlon, por ejemplo. En este caso también podrías usar "-march=i686 -mtune=prescott", así los binarios estarían optimizados para pentium4, pero la arquitectura base sería i686 en lugar de i386.  :Wink: 

----------

## Inodoro_Pereyra

Interesantísimo hilo i92, como siempre, que me lleva a agregar una preguntita a ver si me despejas la duda: Que impacto real en el rendimiento puede llegar a tener un binario compilado con march respecto al mismo compilado con mtune? No debería haber diferencia, verdad? Y respecto al consumo de memoria ram?

Por lo pronto, me voy cambiando de march a mtune ya mismo... Uno nunca sabe cuando se va a quemar una placa madre o algo...  :Very Happy: 

Salud!

----------

## i92guboj

 *Inodoro_Pereyra wrote:*   

> Interesantísimo hilo i92, como siempre, que me lleva a agregar una preguntita a ver si me despejas la duda: Que impacto real en el rendimiento puede llegar a tener un binario compilado con march respecto al mismo compilado con mtune? No debería haber diferencia, verdad? Y respecto al consumo de memoria ram?
> 
> Por lo pronto, me voy cambiando de march a mtune ya mismo... Uno nunca sabe cuando se va a quemar una placa madre o algo... 
> 
> Salud!

 

Todos sabeis a estas alturas que no soy el rey de los benchmarks y que tampoco me preocupan mucho las "optimizaciones".

Así que bajo mi humilde opinión, yo pienso que la diferencia entre -march=k7 con -march=i686 (o incluso i386) es risible en la mayoría de los casos.

Entonces, por la misma lógica casera que uso yo, la diferencia entre "-march=k7" y "-march=i386 -mtune=k7" (o simplemente, -mtune=k7, ya que -march=i386 sería el predeterminado para el compilador x86) es aún más ridícula. Por supuesto, todo depende del programa en cuestión. Un programa que haga uso intensivo de las extensiones de tu cpu tendrá una penalización apreciable en el rendimiento. Pero la mayoría de programas no son así. 

En cualquier caso, ten muy en cuenta que si usas algo como -march=i686 -mtune=k7, entonces tendrás que añadir a mano los flags que añadan sets de instrucciones extra que no estén contenidos en i686. Por ejemplo, -mmmx, o -msse si tu cpu los soporta. En cualquier caso, serás tú quién decida donde quieres poner el límite de compatibilidad, y qué juegos de instrucciones adicionales quieres añadir.

Como ya dije arriba, lo más sencillo en una máquina de escritorio es usar -march y olvidarse del asunto. Pero cada uno tiene sus necesidades y su idea, por supuesto.

Espero que sirva de algo.

Saludos.  :Smile: 

----------

## papu

 *i92guboj wrote:*   

>  *papu wrote:*   
> 
> en el nuevo gcc hay unas opciones que me han liado , de hecho me siempre lo han hecho, yo siempre he usado la opción -march, la -ntune no la entiendo es decir o no entiendo ninguna de las dos. Este es mi make.conf y se puede ver la configuración actual.  En la info del man gcc 4.2.3  se puede apreciar que la opción -ntune tiene  dos opciones nuevas:generic y native.
> 
> Mi pregunta sería entonces que devo poner para tener mejor optimizado: 
> ...

 

Pues aún estoy peor que antes sigo sin entender la diferencia entre -mtune  y -march ,  entonces si con esto ya se detecta porque se ha de poner  -02  o      -ssse3  o las que sean de la cpu que se usa. Que lioso es esto.

En mi caso particular me interesa exclusivamente sacar el maximo partido de mi cpu que es un nocona ( aunque hasta la version 4.3 no se detecta perfectamente mi cpu segun he leído). Entonces que pongo   -mtune i -march=native   o los dos con nocona o solo con uno de los dos me basta.

Con native la detección es la que sale en  /cat/proc/cpuinfo?  

A ver si me aclaro  :Sad:   El problema es que no entiendo lo que hace -mtune y lo que hace -march .

MTUNE  detecta aquitectura y MARCH detecta la cpu en concreto?...   Cual tiene prioridad, y cual se pone antes que el otro en el caso de ponerse ambos.

o simplmente  me olvido de -mtune y pongo -march ya que como no entiendo la diferencia,  lo que me interesa saber es si me va detectar mejor mis insturcciones y caracteristicas poniendo  native o poniendo nocona.

saludos, adéu.

----------

## i92guboj

 *papu wrote:*   

> 
> 
> Pues aún estoy peor que antes sigo sin entender la diferencia entre -mtune  y -march ,  entonces si con esto ya se detecta porque se ha de poner  -02  o      -ssse3  o las que sean de la cpu que se usa. Que lioso es esto.
> 
> 

 

Antes que nada, si no te quieres complicar la vida, simplemente usa -march=native o -march=nocona. Con esto, no necesitas definir -mtune=nocona, para nada. Sería redundante.

 *Quote:*   

> 
> 
> A ver si me aclaro   El problema es que no entiendo lo que hace -mtune y lo que hace -march .
> 
> MTUNE  detecta aquitectura y MARCH detecta la cpu en concreto?...
> ...

 

-mtune *optimiza* para la cpu que le digas, pero, solo usa el juego de instrucciones del 386 (o lo que tu le indiques con -march). Esto significa que -mtune no rompe la compatibilidad. Por ejemplo, si tu usas -mtune=athlon-xp, tu código se optimza hasta cierto punto para athlon-xp, pero sigue siendo posible ejecutarlo en un 386 si fuera necesario.

Si en lugar de -mtune=athlon-xp usas -march=athlon-xp, entonces, gcc además de optimizar para athlon-xp, lo hace usando instrucciones específicas de athlon-xp, esto significa que no podrás ejecutar el programa resultante en ninguna cpu por debajo del athlon-xp. 

Lo de los flags -mmmx, -msse y similares lo explico en un segundo: si usas -mtune=athlon-xp, los binarios resultantes, aunque estén optimizados para athlon-xp, deben ser ejecutables en un 386. Ésto significa que -mtune=athlon-xp se ve forzado a no usar instrucciones mmx, sse, 3dnow ni ext3dnow, porque no son compatibles con la cpu usada como base, qeu sería el i386. Por esto, si usamos -mtune=athlon-xp y no queremos perder dichas optimizaciones, tendremos que especificarlo a mano.

Si usamos -march, entonces no es necesario, porque -march rompe la copmatibilidad, y usa TODOS los juegos de instrucciones de la cpu escogida, sin piedad ninguna  :Razz: 

Espero que aclare algo  :Smile: 

----------

## papu

 *i92guboj wrote:*   

>  *papu wrote:*   
> 
> Pues aún estoy peor que antes sigo sin entender la diferencia entre -mtune  y -march ,  entonces si con esto ya se detecta porque se ha de poner  -02  o      -ssse3  o las que sean de la cpu que se usa. Que lioso es esto.
> 
>  
> ...

 

Bueno entiendo que mtune es mas generico que march y si pongo march ya se sobrentiende lo anterior.

Entonces lo que me interesa saber es si es mejor -march NATIVE o NOCONA  para que detecte todo lo possible,  entiendo que poner   -sse4_1 o -ssse3 sería para activarlas en ciertos programas que si lo usaran aunque el gcc en si mismo no tubiera soporte, no se si estoy en lo correcto.

Pero vamos me intresa el tema de native o nocona jejee.

Native detecta lo que sale en  /proc/cpuinfo ¿no?

muchas gracias

----------

## i92guboj

 *papu wrote:*   

> 
> 
> Bueno entiendo que mtune es mas generico que march y si pongo march ya se sobrentiende lo anterior.
> 
> 

 

No te compliques la vida, Con el tiempo lo entenderás mejor, no es algo fácil de entender si nunca has lidiado con estas cosas. Por ahora, simplemente usa -march. Tanto -mtune como -march aceptan los mismos parámetros.

 *Quote:*   

> 
> 
> Entonces lo que me interesa saber es si es mejor -march NATIVE o NOCONA  para que detecte todo lo possible,  entiendo que poner   -sse4_1 o -ssse3 sería para activarlas en ciertos programas que si lo usaran aunque el gcc en si mismo no tubiera soporte, no se si estoy en lo correcto.
> 
> 

 

Si usas el -march más ajustado para tu cpu, o usas native, no necesitas añadir -msse -mmmx ni ninguna de esas cosas. En man gcc puedes encontrar toda la info relevante, por ejemplo, para nocona, tienes:

 *man gcc wrote:*   

> 
> 
>            nocona
> 
>                Improved version of Intel Pentium4 CPU with 64-bit extensions, MMX, SSE,
> ...

 

Esto quiere decir que, -march=nocona, implica que todas las extensiones citadas serán usadas. Por tanto, añadir -mmmx, -msse, -msse2 y -msse3 sería inútil, porque ya van de serie en el propio -march=nocona.

 *Quote:*   

> 
> 
> Pero vamos me intresa el tema de native o nocona jejee.
> 
> Native detecta lo que sale en  /proc/cpuinfo ¿no?
> ...

 

Si, si tu gcc soporta native, úsalo y te olvidas de historias. En cualquier caso, si pones bien tu -march, y añades cualquier extensión que tu cpu lleve y no vaya implícita en -march=nocona, entonces debería ser lo mismo.

Pero lo dicho: usa -march=native si tu gcc lo soporta, y no tendrás que preocuparte de nada.

----------

## papu

bien  :Smile:   ahora he de despejar el problema de porque mi placa cuando le viene cuelga el pc y se hace un lio a la hora de recuperar su bios ya que es una dual bios,  curiosamente tocando al conector de reset bios se recupera pero tampoco hace lo que deviera que es resetearse,  espero que el tema no vaya a más ya que empieza a ser molesto.

Yo he provado varias distos de linux pero ciertamente gentoo es lo más proximo que conozco a lo que me gustaria que fuera un s.o en terminos de optimizacion y personalización. Lastima que aun cosas como drivers graficos anden bastante lejos de lo que debiera ser pero es lo que digo si quieres algo mejor por lo que no pagas  y te hacen los demás hazlo tu. jejeje

Desconozco si otros s.o basados en linux ( que hay muchos)  son de este estilo nunca he probado un bsd aunque se que gentoo y slackware usan inicialización de scripts de ese estilo o algo parecido  :Smile: 

ya os contaré a ver, saludos  adéu.

 :Very Happy: 

----------

## Inodoro_Pereyra

 *Quote:*   

> bien  ahora he de despejar el problema de porque mi placa cuando le viene cuelga el pc y se hace un lio a la hora de recuperar su bios

 

A ver si adivino: Placa madre nueva, fuente de alimentación vieja?

Salud!

----------

## papu

 *Inodoro_Pereyra wrote:*   

>  *Quote:*   bien  ahora he de despejar el problema de porque mi placa cuando le viene cuelga el pc y se hace un lio a la hora de recuperar su bios 
> 
> A ver si adivino: Placa madre nueva, fuente de alimentación vieja?
> 
> Salud!

 

Lo dudo, en mi firma esta mi ordenador  :Smile:   No se lo que diablos pasa.

A ver como sigue el tema , a esperar una bios nueva del fabricante y como siga ocurriendo la cambio.

saludos, adéu.

----------

## Inodoro_Pereyra

Perdón, no había leído la firma...  Solo hablaba por experiencia personal: Ripple en la salida de la fuente de alimentación = Bios que se borra sola. 

No creo que sea tu caso.

Salud!

----------

## papu

bueno con cierto retardo, explico que todo el problema que tenía de cuelges extraños, reinicios de bios y fallos tremendos de compilación(el windows xp quedó destrozado), cada vez más graves, era a causa de la ram, una ram a 1066 de una calidad teoricamente excelente pero que parece ser tiene incompatibilidades con el chipset x38. Puse otra más "cutrilla" y la cosa va perfecta. Me resistia a pensar que pudiera ser la ram dada la calidad intrínseca de la misma pero parece ser que las empresas venden hardware por defecto muy a límite de sus características como algo con rendimiento extremo pero lo único que consiguen es que sea totalmente inestable y no aseguran un mínimo de calidad( aún suponiendosela), el mismo cuento de siempre.

Me di cuenta de todo esto gracias a los terribles fallos de compilación que sufría bajo gentoo con un comportamiento totalmente aleatorio , eso me hizo cambiar los modulos( suerte tenía otros) y bueno era eso.

Ahora va todo como devería pero en el grub sigo teniendo que entrar manualmente y no entiendo que diablos pasa la verdad, pero bueno eso es un mal menor aunque molesto y extraño.

----------

## Coghan

 *i92guboj wrote:*   

> Asumo que quieres decir "-mtune", no "-ntune".
> 
> Si es así, entonces la diferencia entre ambas banderas es sutil, pero muy importante: -mtune, por si sola, optimiza para el procesador escogido (o para el detectado, si usas native). Pero, y aquí está la diferencia, -mtune jamás genera código que no pueda correr en la arquitectura base (i386 o x86_64, según el caso).

 

Todo lo siempre quise saber sobre -march y -mtune resumido en una simple frase. "Me encanta este foro".     :Cool: 

Al caso, aprovecho este hilo pues para no abrir otro nuevo. Por fin me he visto con fuerza para instalar en mi portátil ~amd64 enterito y bueno a pocos días de pasar el stage3 nuevito a ~arch y hacerle un emerge -e world con las gcc-4.2.4 me encuentro hoy con la actualización a las gcc-4.3.1 (es lo que tiene estar en test, las actualizaciones van más rápido), el tema que viendo los cambios entre versiones la primera que me encuentro es el FLAGS opteron-sse3, mi procesador es un turion64 y aún no aparece como tal.

Ahora mismo estoy compilando gcc-4.3.1 pero no me atrevo a activarlo con gcc-config por dos motivos, el primero es que no se si esperar algunos días o semanas no sea que le hagan un hard-masket y el segundo me pesa realizar de nuevo un emerge -e world.

Según el manual de actualzación gcc lanzando: 

```
fix_libtool_files.sh 

emerge --oneshot -av libtool
```

 debería ser suficiente, y recompilar el kernel, pero recomiendan para estar 100% seguro hacer el emerge -e. Es probable que me tire a la piscina y lo deje fijando las librerías, si más adelante me encuentro algún contratiempo pues veré como lo voy solucionando, seguro que me sirve de más experiencia.

----------

## papu

hola de nuevo , comentar que el tema grub ya va, curiosamente hoy tras entrar en gentoo ha funcionado el solito como antes O_O.

Referente a cambiar de gcc yo como solo he usado versiones gcc 4.x.x uso el sistema mas rápido sacado de la misma pagina que has puesto tu de gcc :  Using revdep-rebuild.

Estoy compilando el nuevo 4.3.1 que teoricamente samejor soporte para mi cpu ahora mismo estoy recompilando el kernel.

```
New Targets and Target Specific Improvements

IA-32/x86-64

    * Tuning for Intel Core 2 processors is available via -mtune=core2 and -march=core2.

    * Tuning for AMD Geode processors is available via -mtune=geode and -march=geode.

    * Code generation of block move (memcpy) and block set (memset) was rewritten. GCC can now pick the best algorithm (loop, unrolled loop, instruction with rep prefix or a library call) based on the size of the block being copied and the CPU being optimized for. A new option -minline-stringops-dynamically has been added. With this option string operations of unknown size are expanded such that small blocks are copied by in-line code, while for large blocks a library call is used. This results in faster code than -minline-all-stringops when the library implementation is capable of using cache hierarchy hints. The heuristic choosing the particular algorithm can be overwritten via -mstringop-strategy. Newly also memset of values different from 0 is inlined.

    * GCC no longer places the cld instruction before string operations. Both i386 and x86-64 ABI documents mandate the direction flag to be clear at the entry of a function. It is now invalid to set the flag in asm statement without reseting it afterward.

    * Support for SSSE3 built-in functions and code generation are available via -mssse3.

    * Support for SSE4.1 built-in functions and code generation are available via -msse4.1.

    * Support for SSE4.2 built-in functions and code generation are available via -msse4.2.

    * Both SSE4.1 and SSE4.2 support can be enabled via -msse4.

    * A new set of options -mpc32, -mpc64 and -mpc80 have been added to allow explicit control of x87 floating point precision.

    * Support for __float128 (TFmode) IEEE quad type and corresponding TCmode IEEE complex quad type is available via the soft-fp library on x86_64 targets. This includes basic arithmetic operations (addition, subtraction, negation, multiplication and division) on __float128 real and TCmode complex values, the full set of IEEE comparisons between __float128 values, conversions to and from float, double and long double floating point types, as well as conversions to and from signed or unsigned integer, signed or unsigned long integer and signed or unsigned quad (TImode) integer types. Additionally, all operations generate the full set of IEEE exceptions and support the full set of IEEE rounding modes.

    * GCC can now utilize the ACML library for vectorizing calls to a set of C99 functions on x86_64 if -mveclibabi=acml is specified and you link to an ACML ABI compatible library.
```

referente a esto uso usando -march=native ( me pilla todo incluso sse4.1) no se si poner a mano esta opción

* A new set of options -mpc32, -mpc64 and -mpc80 have been added to allow explicit control of x87 floating point precision.

o si es interesante tampoco se muy bien su utilidad, ¿que opináis?

saludos, adéu

----------

