Barrapunto

Una semana, y es un excelente compilador. El problema es que el código c++ que circula por ahí, en la mayoría de proyectos, siguen de forma un tanto "informal" el estandar ansi y ahora que gcc se ha tomado en serio ser compatible, ese código no compila.

Era una pena que hubiera que usar otros compiladores, como el de Microsoft (Sí, el mismo) para poder compilar código conforme al estandar. Por suerte, eso ya no es necesario :-)

Estoy pensando en instalarlo en mi maquina (FreeBSD), pero no estoy seguro del todo, porque no si los ports compilaran como es debido.

Estoy interesado porque en SlashDot dicen que GCC 3.x es bastante mas rapido que la version 2.95 (la que viene en FreeBSD).

Alguien con algun comentario util acerca de esto?

Pues yo lo tengo compilado con GCC 2.97 y XFree 4.1.0.1 y no va mal. Alguna cosa no compila, otras no van muy finas pero en cuanto Debian ponga la versión estable en unstable (ya tenian la pre) lo recompilo TODO.

Que mucho curro?

Para eso estan los scripts, los hazes una vez y los usas un monton de vezes ;-)

Pues eso que os ahorro los comentarios.

Se trage el codigo c++ más rápido, sí. Además tiene nuevas opciones de optimización (ojo, que yo di el salto 2.95-3.2 y puede que esto no sea tan nuevo), más warnings por defecto, etc.

de velocidad de apertura de programas en C++? tenia entendido que con gcc 3.2 y las nuevas binutils y glibc la cosa cambiaria bastante, pero no veo ninguna noticia al respecto. Alguien podria decir algo sobre como la cosa y si hay futuro prometedor en este campo? creo que para aplicaciones C++ es algo importante, porque solo por el hecho de ver arrancar una aplicacion de manera lenta, ya parece que el propio programa en si es lento, y no tiene nada que ver una cosa con la otra.

Yo uso Gentoo, y mi unico compilador es gcc3.1.1, 3.2 a partir de ahora.

La diferencia a nivel de optimizacion a partir del 3.1 es bastante importante segun la gente de gcc, aunque yo note mucho el salto porque pasar de Debian/386/gcc2 a Gentoo/gcc3.1/-march=athlon -O3 -fomit_frame_pointer

Ahora estoy usando rmerge para recompilar mi sistema entero con la abi nueva... espero que en un par de dias este todo listo :).

Igual, o una diferencia tan marginal que no se ve la diferencia.

Me parece que es mejor haCer la corrección una vez ;-)

Lo siento por el Troll ortográfico, no me pude resistir.

Recuerdo que gcc-3.0 compilaba Linux de forma incorrecta y además era más lento que gcc-2.95

¿Se puede compilar Linux con gcc-3.2 sin problemas?
¿Es más rápido?
¿Alguna referencia a estas preguntas?
 

No, no se puede compilar el kernel sin parchear. Con él puedes arrancar pero suelta panics de vez en cuando.

Hay parches, como con todo, pero por defecto no se puede.

Voy a estudiar si compilar produce alguna estimulación de alguna parte escondida del cerebro, que produzca sensaciones placenteras o una secreción de adrenalina anormal.

El ultimo beta de Mandrake sigue con gcc 3.1.1 mientras que el beta de RedHat (limbo) trae el gcc 3.2 (por ahora solo lo pueden ver en rawhide, pero en estos dias esta saliendo una nueva version de limbo).
Esto hace suponer incompatibilidad entre las proximas versiones de Mandrake y RedHat.
Me parece extra#o que la gente de MDK no espere (como de costumbre) a que RH saque una version x.0 para sacar su (x+1).0 compatible (los binarios) con RH.
Si esto sale asi: que van a hacer los chicos de MDK con la version que le siga? MDK 10.0 o un 9.1 que es incompatible con 9.0 ?
el tiempo dira...
   

Es suficiente mirar el changelog para no equivocarse (busca gcc).

Pues los flags y opciones de compilacioin se los puedes pasar igualmente al gcc versión "antigua"... y eso desde la debian hasta mandrake, otra cuestion es que no sepas compilar desde lo sources si no te dan un sistema facil como gentoo,(por cierto, ¿sabes que tambien puedes usar binarios?). Ademas me da la impresion que no pasas bien las opciones al compilador, haz un man gcc o mirate bien la documentacion de las nueva version, pq usas opciones "antiguas"....

Mandrake usa GCC-3.2, por lo menos en sus versiones de desarrollo desde hace unos tres dias ya las usa (desde bastante mas tiempo estaba marcado como GCC-3.2 el comppilador). El KDE ya esta compilado con estas librerias por ejemplo, asi como el kernel y las XFree. Yo estoy con la version 9.0 (sera la beta que sea puesto que instalo directamente todos los paquetes de desarrollo). Esto es asi puesto que alguans aplicaciones que todavia no estan actualizadas en los ftp no arrancan :

k3b: /usr/lib/libstdc++.so.5: version `GLIBCPP_3.1' not found (required by k3b)

resta solo esperar que las actualicen a probar a compilarlas desde los suorces.

las aplicaciones que se van actulaizando ya piden el nuevo GCC:

nombre sakuraplayer sumario KDE2/3-based player for tfmx music from the Amiga versión 2.0.0-3mdk
depender /bin/sh(),...---(varias librerias mas...)---,libXt.so.6(),libz.so.1(),libc.so.6(GLIB C_2.0)(),libc.so.6(GLIBC_2.1.3)(),libstdc++.so.5(G LIBCPP_3.2)() sakuraplayer distribución Mandrake Linux vendedor MandrakeSoft

Como se puede ver este paquete actualizado ya pide el nuevo GCC-3.2...

De hecho mi sistema funciona con la nueva GCC y en cuestion de una semana imagino qu ehabran pasado todo el sistema a la nueva libreria

Que curioso, a mi me ha pasado todo lo contrario, los ejemplos de C++ del libro de Bjarne Stroustrup no han llegado a compilar nunca con el compilador M$. Puede que g++ abuse de la norma ANSI (p.e. utiliza por defecto el namespace std y eso lleva a ciertos problemas de portabilidad), pero el compilador de microsoft se pasa todos los estandares por el forro del precompilador. Además, como la biblioteca std no entra en la norma se la pasan por el forro. Aun no he conseguido que compilase algo tan simple como std::cerr
Más casos, un amigo hizo un visor de escenas que compiló en todos los compiladores que probé (g++, borland y watcom) arreglando lo del "using namespace std;" que el g++ presupone (¿presuponía?) pero en el de m$ me dieron ciento y pico errores todos ellos en sitios que no tenían sentido (y más aun teniendo en cuenta que en todos los demás compilaba sin ni un sólo warning). Con los ejemplos de Stroustrup más de lo mismo, el único compilador en el que no conseguí hacerlos tirar fue el de microsoft.

Me habrás notado un poco quemado, pero es que salí escaldado. El IDE de m$ me encantó a primera vista (ahora que ya he visto un poco más de mundo lo cierto es que no me parece tan magnífico), lo vi completísimo y muy bueno vaya, pero cuando empezó a hacer eso me hundió en la miseria...

prueba -ffast_math, a mi me iba de PM en el 2.96 y no daba problemas.

Definitivamente, si.

Bueno, si bien es cierto que las opciones las puedes pasar tb a un gcc antiguo, tambien es cierto que -march=athlon existe solo en gcc>=3.

Lo de las opciones antiguas... estan todas en la manpage de gcc 3.2, y ninguna esta marcada como deprecated. Que parametros me propones tu para el gcc3.2?

Por otro lado creo que sé compilar desde sources... aunque tu comentario tenia sus cosas interesantes, esta provocación te la podias ahorrar perfectamente. Insistiendo sobre lo mismo, te diré que estoy cansado de oir memeces del tipo Gentoo=elitista o Gentoo=LFSparatontos, comentarios de los que ya estaba cansado como usuario de Debian que soy y sigo siendo, comentarios que casi siempre vienen de algun tipo de sectarismo a una distribución concreta. Como siempre he dicho, que cada uno use la distro que quiera y haya paz y despues gloria.

Cuando me compré un HD nuevo hace un par de meses se me ocurrio pensar en compilarlo todo desde cero, mas que nada a modo de experimento, tenia curiosidad por ver si se notaba o no el hecho de optimizarlo todo, contra los paquetes Debian/386 que estaba acostumbrado a usar. Consideré partir del base de Debian, pero pronto concluí que si no iba a usar el sistema base para nada, me salia más a cuenta montarme un LFS. Entonces comentandoselo a un amigo me habló de Gentoo, y pensé que por probarla no perderia nada. Y en fin, asi lo hice, y no miento si digo que de momento estoy bastante contento con ella, puesto que me permite mantener una instalacion con lo-ultimo-de-lo-ultimo (padezco versionitis, si) y hacerlo sin tener que dedicar una enorme cantidad de tiempo, tiempo que puedo dedicar a cosas más interesantes; que un sistema operativo es poco útil si tienes que dedicarte a él todo el tiempo.

El kernel compila perfectamente con gcc 3.x. De hecho, lo llevo haciendo asi desde gcc 3.0.4 (3.0.3 petava al compilar el modulo de rtl8139). No es necesario ningun tipo de parche. Por otro lado, el que llevo ahora mismo es un 2.4.19 con el parche "grande" del XFS, compilado con 3.1.1.

Es más rapido? Teoricamente si lo és, aunque no se hasta que punto se nota eso. Yo noto bastante el tener _todo_ el sistema compilado con 3.1.1 para mi maquina (Gentoo), comparandolo con Debian/Unstable/386. Pero claro... compilando solamente el kernel quiza ni se note.

He escuchado, que el KDE funciona más rápido, compilado con gcc3.x es cierto esto? ocasionaría incompatibilidades?

Falso como una moneda de 3?, va mas rápido, de hecho han integrado el código del famoso objprelink en el gcc 3.2, con lo que hay ganancia seguro. De hecho el autor del objprelink ha sacado una nueva versión del programa objprelink2 que consigue otro 50% de ahorro en el tiempo de carga de las librerías dinámicas, aunque el tambien dice que no cree que eso afecte mucho por noseque cosa que no terminé de leer del artículo.
 
Saludos

Con el Visual C++ versión 5.0 y superiores nunca he tenido problemas, y el soporte de la biblioteca estandar, en mi humilde opinion, es (o era) mejor que el de g++

Todo lo falso que tu quieras, pero esto va igual.

Con un 2.4.18 el kernel compila, pero al arrancar da panics en el modulo 3c59x, en el autofs, etc.

¿Qué depende de la máquina?, a lo mejor: yo tengo un PIII y ese es el resultado compilado con gcc3. El mismo kernel compilado con el 2.95 es perfectamente estable.

Porque estoy probando el apt-build de Debian y con el 3.1 no me compila, por poner un ejemplo galeon.

El programa ya avisa de que algunos programas podrían no funcionar.

También leí en algún lado que Debian iba a hacer de gcc 3.2 su nuevo compilador estándar pero me extraña que dejen de lado el 2.95 si el núcleo no compila con gcc 3.x y otros programas fallan

El nucleo sí compila, lo que ocurre es que pueden aparecer inestabilidades

Estimado amigo:

En ningún caso te tomes mi comentario como algo personal, si quizás pueda ser un tanto provocativo y es algo a lo que los usuarios de sistemas libres estamos acostumbrados :o).

  Yo también utilizo Gentoo ;) aunque despues de leer en el foro sobre GCC-3.x todavía no me he decidido a cambiarlo, ni siquiera a instalarlo...(no todas las aplicaciones están preparadas para compilar con el nuevo GCC por lo que se puede leer en los changelog y en los package.mask), aunque el nuevo GCC ya viene desmarcado todavia tiene que convivir con el antiguo y se necesita dar las opciones de compilacion con uno u otro "a mano" dependiendo del programa que quieras compilar, en breve esto se realizará de modo "automágico".

También utilizo Mandrake, la cual actualizo regularmente desde los servers ftp de desarrollo, desde los .srpm o como ahora con el cambio a GCC-3.2 con binarios, puesto que es un verdadero lio compilarlo todo (tengo casi todo el software que hay en los servers...) :D y no soy un gurú informático, así que también pertenezco al tipo de gente "versionada" y a la cual le gusta probralo todo, por le placer de hacerlo y por aprender ;)

Una cosa, lo que no utilizo en absoluto es M$ xDDDDD (lo siento, pero para usar un ordenador ni hace falta ser un gurú, ni se necesita en absoluto nada que provenga de M$) jeje.

  Así pues, para estar a la última nada mejor que los sistemas libres, los cuales puedes actualizar a diario, ajustar a tus necesidades, crearlos a tu gusto o seguir con una slack y un kernel de la serie 1.x.x sin problemas...

Espero no resultar provocativo en otra ocasión, aunque como dices que cada uno use la distro que quiera que para eso este sistema ofrece la posibilidad.. ;D

larga vida a GNU y los sistemas libres y ¡viva la autocritica!.

Por cierto que no noto mucho cambio en la velocidad de ejecucion de los programas en la mandrake con el nuevo GCC si bien creo que las mejoras del compilador van más allá unicamente de la velocidad de ejecución... comparad un LINUX de hace dos años con lo quie teneis ahora... estabilidad, velocidad, facilidad de uso, portabilidad, plataformas soportadas, hard soportado....

 

Con el Visual C++ versión 5.0

Era la versión 6.0 y ya te digo, la biblioteca estandar se la han pasado por el forro de los cojones. Hay una pseudo-norma no incluida en la norma ANSI, y como no está en la norma se montan su propia stdlib y no se han saltado el estandar aunque luego los programas que compilan en todas partes no compilan en VC++ y viceversa. Ya te digo que si no me crees prueba a compilar algo tan simple como std::cerr
Ya te digo que si he detectado algunos fallos con el g++, pero mucho más gordos han sido los que he detectado con el compilador de m$, por eso te digo que me parece raro que tú (o el anterior) recurras al compilador de m$ para solucionar ese tipo de problemas cuando para mi ha sido una fuente de problemas. Experiencias contrapuestas como ves...

Es que ya lo he probado y compila :-). Uno de los dos está haciendo algo mal... O yo tengo la mega-versión "cliente-contento"

(Soy el mismo)

Sera por otros motivos. Mi galeon ha estado compilado con 3.1 y 3.1.1 funcionando perfectamente (es mi navegador habitual) y cuando le toque el turno con gcc 3.2 (estoy recompilandolo todo por el tema del cambio de ABI...).

Probablemente el problema este en que tienes Mozilla compilado con un gcc distinto con una ABI distinta.

Si te animas a pasarte a 3.2 (recuerda que no necesitas hacerlo para nada, pedes seguir con 2.x, pero doy fe que gcc3 ya esta a la altura), un gentooero se ha currado un script muy bonito para recompilarlo todo, teniendo unos flags alternativos para las compilaciones que fallen (algunos programas fallan al compilar con -O3 y compilan perfectamente con -O2), y podiendo resumir por donde estabas en caso de error.

Por otro lado, deberias cambiar el make.profile para que apuntara al default-2.0-x86 o algo asi, el de gcc3.2, y actualizar el gcc antes de ejecutar el scriptillo.

El programilla en cuestion se llama rmerge, y puedes encontrar un enlace a él en el post sobre recompilar todo en el foro gcc3 de forums.gentoo.org. El autor lo ha colgado de la base de datos de bugs como ebuild nuevo, y probablemente este disponible en portage en breve.

Llevo unas 16 horas compilando... quiza todavia tarde un par de dias, pero si ocurre algun desastre lo postearé para que no te ocurra también. De todas formas, no creo que ocurra nada, y casi todo se puede arreglar...

Por curiosidad, ya de paso, he añadido el -fomit_frame_pointer en los FLAGS, que alguien me lo recomendo diciendome que en Athlon se nota bastante. Ya veremos si sale bien el experimento.

Que gcc usaste exactamente? Los primeros gcc3 sí daban problemas... petaban por todas partes. Por suerte ha llovido mucho desde entonces.

En caso de que usaras algo mas bien reciente, es probable que sea un caso raro y aislado a tu maquina. Conozco a bastante gente que tiene el kernel compilado con gcc3.x, de hecho, una parte enorme de los usuarios de Gentoo lo estan usando ya para absolutamente todo, incluido el kernel.

En fin... muchas de las beta de las nuevas versiones de distros, como mandrake, estan usando ya gcc3.x para absolutamente todo. Pronto nos olvidaremos definitivamente de gcc2 :).

Ese error es caracteristico al intentar linkear programas con librerias compiladas con ABIs distintas. Deberia solucionarse al actualizar todo a paquetes compilados con gcc3.2.

Doy fe de ello. En mi maquina se ha notado bastante el paso de gcc2 a gcc3.x en el caso de KDE, y asi lo he oido tambien de mucha gente, muy probablemente por el tema del object prelinking, que se supone acelera bastante la carga de programas escritos en c++, como es el caso de todo el entorno KDE.

tux@moo tux $ sensors
w83782d-i2c-0-2d
Adapter: SMBus Via Pro adapter at e800
Algorithm: Non-I2C SMBus adapter
VCore 1: +1.64 V (min = +4.08 V, max = +4.08 V) (beep)
VCore 2: +0.04 V (min = +4.08 V, max = +4.08 V) (beep)
+3.3V: +3.45 V (min = +2.97 V, max = +3.63 V) (beep)
+5V: +5.02 V (min = +4.50 V, max = +5.48 V) (beep)
+12V: +12.20 V (min = +10.79 V, max = +13.11 V)
-12V: -12.29 V (min = -13.21 V, max = -10.90 V)
-5V: -5.36 V (min = -5.51 V, max = -4.51 V)
V5SB: +0.13 V (min = +0.13 V, max = +0.13 V)
VBat: +0.08 V (min = +0.08 V, max = +0.08 V)
fan1: 4927 RPM (min = 3000 RPM, div = 2) (beep)
fan2: 468 RPM (min = 187 RPM, div = 32) (beep)
fan3: 0 RPM (min = 3000 RPM, div = 2)
temp1: +39°C (limit = +60°C) sensor = thermistor (beep)
temp2: +58.5°C (limit = +60°C, hysteresis = +50°C) sensor = thermistor (beep)
temp3: +255.5°C (limit = +60°C, hysteresis = +50°C) sensor = 3904 transistor
vid: +2.600 V
alarms:
beep_enable:
                    Sound alarm disabled
 

Según gcc -v:

gcc versión 3.2 20020720

Compilado por mí.

Además, los fallos son un tanto "inexplicables", aleatorios y de los que depuras para acabar encontrando nada de nada... Y como ya digo con el gcc2.95 no pasa, así que la culpa se la achaco al compilador.

Ahora que me dices que a ti te funciona supongo que lo que ocurre es que no estás compilando las fuentes originales del kernel. Gentoo, igual que rh, debian, etc, habrá metido sus propios parches al núcleo y puede que esos parches mejoren la compatibilidad de los fuentes de cara a compilarlos con gcc3.

Otra posibilidad es que se dé la puñetera mala suerte que sólo fallen los módulos que tienen que ver con mi hw :-)

Con una glibc, binutils y un cargador dinámico que usen combreloc, la lentitud en la carga de símbolos dejó de ser problema *antes* de que saliera este gcc3.2.

Y de todas formas esa mejora sólo se nota durante la carga de las aplicaciones (el tiempo de arranque se acorta). KDE seguira yendo igual de lento o de rápido que antes.

Hombre, supongo que habra que indicarle al gcc que use objprelink, no creo que lo utilize por defecto para compilar. LA diferencia en kde usando objprelink (aunque sea con un gcc normal 2.95 o 2.96) se nota mucho, por ejemplo el konqueror pasa de arrancar en 6 a 7 segundos a 1 o 2.

SAlud2 !!!

Precisamente la lentitud del kde siempre ha sido en la carga de los programas (aunque yo como utilizo desde hace mas de 1 año paquetes "objprelinkeados" nunca lo he notado), una vez cargados los programas estos van rapido de sobra.

Ahh y el objprelink no solo acelera kde y software hecho en C++, se puede objprelinkar todo el soft incluidas librerias del sistema, con todo el sistema optimizado de esta manera se consigue una mejora apreciable en la velocidad del sistema.

Salud2 !!!

Precisamente, el problema del "objprelinkeado" (menudo palabro que te has inventado, quillo :-)) está resuelto de forma *independiente* al compilador.

Da igual que compiles con el 3.2, el 2.95 o lo que quieras, lo importante es que tus binutils (el enlazador) incluya soporte para combreloc o uses eso del objprelink.

El combreloc es una solución mucho más general y está disponible desde hace tiempo. No tiene sentido que la peña diga "Sí, sí: compila con el 3.2 que el kde te va a cargar más rápido". Es falso, puede incluso que vaya más lento puesto que depende del enlazador y del cargador y *no* del compilador (bueno, sí depende del compilador, pero no lo de los símbolos. No sé si me explico)

En fin, ya he comentado tres veces lo mismo.

El "objprelink" de gcc3 es un proceso que se realizaría durante el enlazado, gcc ahí no interviene. Es ld quien se ocupa de eso.

Sin unas binutils adecuadas no hay ganancia, por mucho gcc3.2 que uses.

Y de igual forma, con un compilador más antiguo más el enlazador adecuado el proceso se llevaría a cabo de igual forma. Basta con un LDFLAGS="-z combreloc" y un cargador ld.so que lo soporte.

Eso es lo que quería decir en el comentario anterior.

En Gentoo tienes bastantes kernels para escojer.

vanilla-sources son tal cual de kernel.org

gentoo-sources superparcheados, con preempt, lowlat, XFS...

En mi caso me bajé el vanilla-sources y apliqué unicamente el parche del XFS.

Tu caso es muy muy raro. Te sugiero que pruebes con el gcc3.2 definitivo (que en 20020720 no existia ni de lejos...).

¡oido barra!

Pues voy a chrootear la partición gentoo y a actualizarlo todo :)), me has animado, de momento la mandrake va bien, ya la tengo casi toda pasada a GCC-3.2 y estoy bajando los sources que todavia no han actualizado (yo tpc puedo esperar :o).

...por cierto.. ¿no es una verdadera maravilla poder seguir trabajando con el pc mientas actualizas dos distribuciones a la vez sin tener que rebotar dando servicios de ftp, web y ssh, mientras ves la televisión o haces lo que te canta el culo ? :D

Larga vida a GNU y los sistemas libres, todavía hay gente que duda de todo esto jajajajaj.. ¡increible!

Mi sistema es un P-III 1000 con 296 de RAM los flags de compilacioin son:

-march=i686 -O3 -pipe -ffast-math -fomit-frame-pointer -w

Por lo menos el objprelink standard que existe desde hace casi 2 años no necesita ningunas binutils especiales para su funcionamiento, se puede aplicar a cualquier sistema y a cualquier compilador de gcc.

Salud2 !!!

Creo que por ahí van los tiros porque me he dado cuenta de que el g++ que usa al compilar es el 2.95 y el gcc es el 3.1. Obviamente habrá alguna incompatibilidad entre los dos y casi seguro que es un bug de los paquetes que uso.

Ganas tengo de probar Gentoo. A ver si sacan CDs nuevos con otro núcleo porque en el que usé la última vez la tarjeta de red no funcionaba bien.

Pues es curioso, ya te digo que no te miento (tengo testigos), el std::cerr desaparecido y en la ayuda no decía nada de él. Pero vamos, que ya te he dicho también que ese sólo era un ejemplo, me han comentado (no lo he comprobado) que los problemas más grodos venían con las clases string que, como la biblioteca std, no entran en la normal ANSI. Pero te aseguro que he tenido muchos problemas, y como ya te he dicho dos veces, el más cantoso fue el del libro de Stroustrup, no podía creerme que no compilase una cosa tan simple (menos de 200 lineas) y que además me compilaban todos los demás compiladores. Pero vamos, si me dices tú que no has tenido problemas en ese sentido te creeré, sigo sin saber donde podía estar el problema pero tampoco lo usé tan extensamente como al parecer tú así que supongo que tu experiencia es más válida que la mía que sólo lo usé unos meses.

1 saludo!

Lo he entendido hasta yo...