# consulta por paquetes de system

## pelelademadera

tengo una duda acerca de los paquetes como gcc, glibc y demas

recuerdo una vez que instale gentoo todo con ~amd64 y no pude compilat tvtime por problemas con glibc, desde esa vez bloqueo versiones de glibc y de gcc a la 4.3.2 que siempre me funcionaron bien.

mi consulta es la siguiente.

hay algun beneficio en actualizar a gcc4 por ejemplo? y que diferencia hay en las versiones de glibc?

no me refiero a la compilacion del paquete sino al paquete ya compilado.

y otra consulta es si puedo decirle a portage que cuando haga un

emerge -DuNav world, no actualize nada de system

graciela

----------

## gringo

 *Quote:*   

> recuerdo una vez que instale gentoo todo con ~amd64 y no pude compilat tvtime por problemas con glibc

 

ese es el precio que se paga por usar ~arch: a veces las cosas no funcionan a la primera ( o simplemente no funcionan). Si no quieres problemas usa estable.

 *Quote:*   

> hay algun beneficio en actualizar a gcc4 por ejemplo? y que diferencia hay en las versiones de glibc? 

 

por norma pienso que siempre es bueno tener una versión mas reciente, ya no porque vaya a haber mas funcionalidades, si no porque seguramente se hayan solucionado un huevo de bugs. Gcc y glibc son paquetes importantísimos para un sistema como gentoo, ahora bien, un salto en la versión del gcc p.ej. no es algo trivial, y se sugiere recompilar todo el sistema.

Esto tampoco quiere decir que hay que ir corriendo a tener todo a la última ( lo que yo llamo "versionitis") : si todo te funciona bien, con eso llega no ?  :Smile: 

 *Quote:*   

> cuando haga un
> 
> emerge -DuNav world, no actualize nada de system 

 

no estoy seguro al 100% pero en caso de que uses la versión 2.2 de portage, world y system son sets distintos y world ya no engloba a system, asi que si haces un emerge -uNav @world tan sólo debería actualizarte lo que tengas en el world. Si añades -D tb. buscará mas profundamente en las dependencias y seguramente te añada algún paquete de @system. ( no sé si el soporte para sets está en la verisón ~arch de portage ...)

saluetes

----------

## ensarman

recuerdo que cuando pase a ~arch me fue muy dificil, pero muchas veces la solucion la encontaba en el bugzilla

----------

## pelelademadera

claro, mi pregunta apuntaba a lo que dice gringo.

haco bocha que estoy en ~amd64, pero siempre tube esa duda, y la mejor solucion fue ir bloqueando a mi gusto ciertas cosas, me parecio mas facil que destrabar todo. a veces se pone denso el asunto.

lo que yo preguntaba era si habia alguna forma de bloquear todo @system, o sea, que la unica forma de que se actualice sea haciendo un emerge -Du system.

y la pregunta acerca de gcc y glibc, era si en el codigo final hay diferencias? xq supongo q gcc4.4 sera mejor para por ejemplo un i5/i7, yo tengo en estos momentos un E7400, y gcc 4.3 soporta todas sus extensiones.

y otra pregunta q me olvide de hacer es, todo lo que se pone en: CFLAGS= hace a las optimizaciones de la compilacion y de la ejecucion del programa, o solo de la compilacion?

y otra pregunta era, si puedo compilar con mi intel, un sistema gentoo para usar en un barton o en algun sempron y poner en CFLAGS= las 3dnow de los amd?, mi intel puede compilar eso? o no?

graciela gente, y perdon x mi ignorancia. lo poco q se lo se de toquetear, ni siquiera estudio algo relacionado... es medio q un quilombin todo esto

----------

## Inodoro_Pereyra

 *pelelademadera wrote:*   

> claro, mi pregunta apuntaba a lo que dice gringo.
> 
> haco bocha que estoy en ~amd64, pero siempre tube esa duda, y la mejor solucion fue ir bloqueando a mi gusto ciertas cosas, me parecio mas facil que destrabar todo. a veces se pone denso el asunto.
> 
> lo que yo preguntaba era si habia alguna forma de bloquear todo @system, o sea, que la unica forma de que se actualice sea haciendo un emerge -Du system.

 

Colaboro con lo poco que puedo: Que yo sepa no se puede "congelar" system como está, pero la salida de emerge -pe @system te muestra la lista completa de paquetes que contiene el set (144 en mi caso).

Si realmente te interesa bloquear todos esos paquetes para que no suban de versión, de la salida del comando, pipe a un archivo, un poco de limpieza y a package.mask. Supongo que a la larga no puede ser mas que para problemas, pero...

 *pelelademadera wrote:*   

> y otra pregunta era, si puedo compilar con mi intel, un sistema gentoo para usar en un barton o en algun sempron y poner en CFLAGS= las 3dnow de los amd?, mi intel puede compilar eso? o no?
> 
> graciela gente, y perdon x mi ignorancia. lo poco q se lo se de toquetear, ni siquiera estudio algo relacionado... es medio q un quilombin todo esto

 

Si que se puede. Necesitas el toolchain para la arquitectura que vas a utilizar. Si tu core2 corre a 64 bits vas a necesitar el toolchain i686-pc-linux-gnu para un Athlon XP por ejemplo.

El paquete sys-devel/crossdev puede gestionar todo esto por vos tranquilamente, lo uso siempre para distribuir la compilación por la red usando distcc.

Por otro lado, si estás por construir un Gentoo desde cero en tu core2 para correr en el Athlon XP ese, entonces no hace falta ningún toolchain nuevo, la jaula chroot ya contiene el toolchain correspondiente y gcc generará el codigo como le hubieras especificado en make.conf.

Si tu core2 corre a 64 bits multilib, chroot se ejecuta:

```
linux32 chroot /mnt/gentoo /bin/bash
```

Salud!

----------

## pelelademadera

claro, esa era mi idea, construir un gentoo en el core mio, para el athlonxp, con 3dnow y demas... ya que con el athlon me va a llevar un tiempito mas....

gracias a todos

----------

## Inodoro_Pereyra

Lo mas rápido (lo que suelo hacer siempre que puedo) es bootear un livecd cualquier, exportar / con NFS y montarlo por la red desde una pc mas potente.

Desde la pc potente, haciendo chroot al punto de montaje que contiene el / de la otra pc se puede seguir el handbook sin inconvenientes. La instalación se hace directamente sobre la pc que corresponde, pero por la red, aprovechando toda la potencia del mejor microprocesador.

También monto la carpeta /usr/portage/distfiles desde alguna otra pc de la red que la conenga en el punto de montaje que contiene / de la pc menos potente, con eso me ahorro descargar paquetes dos veces.

Salud!

----------

## luispa

 *pelelademadera wrote:*   

> 
> 
> hay algun beneficio en actualizar a gcc4 por ejemplo? y que diferencia hay en las versiones de glibc?
> 
> 

 

actualicé a gcc4 y recompilé "todo", el beneficio: un aumento en el rendimiento y como beneficio adicional me forzó a limpiar algunas cosillas  :Smile: . Las versiones que tengo son:

```

sys-devel/libtool-2.2.6a

sys-devel/gcc-4.4.2

sys-devel/binutils-2.18-r3

sys-libs/glibc-2.9_p20081201-r3

```

luis

----------

## i92guboj

Como norma general, cada versión del compilador produce código más limpio, más eficiente, y menos propenso a errores (siempre que no uses un compilador experimental, claro). También se van añadiendo arquitecturas, y afinando las ya existentes para un mejor aprovechamiento del juego de instrucciones de cada una.

----------

## pelelademadera

bueno, gracias entonces por lo de gcc. vuy a subir a la 4.4.2. a ver q onda.

con el tema de glibc?

----------

## luispa

yo utilizo la versión que te puse arriba de glibc, me va perfecto (x86_64)

luis

----------

## pelelademadera

bueno, cuento que actualize a gcc-4.4.2, anda todo joya, salvo que no puedo compilar mysql community, que era el que usaba. me pase al mysql generico y como trompada. asi que vamos a ver que tanto cambio esto.

gracias a todos. se puede cerrar

----------

