# [segfault] Firefox peta tras actualizar zlib *ok*

## jmp_

=== 

Solución, si has actualizado zlib, recompila usando flags más seguros que no incluyan -fomit-frame-pointer.

```

vim /etc/make.conf --> CFLAGS=-march=<tu arch> -O2 -pipe 

emerge zlib

```

===

Hola,

No puedo arrancar firefox ni firefox-bin, me da un segmentation fault.

Me ha ocurrido esto al actualizar Zlib tanto en el portátil como en la workstation:

```

~ $ firefox

No running windows found

/usr/libexec/mozilla-launcher: line 117: 27623 Violación de segmento  "$mozbin" "$@"

firefox-bin exited with non-zero status (139)

```

Mis CFLAGS Flags:

```

CFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer -msse2 -ftracer -fweb -ftree-vectorize -fstack-protector-all"

CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"

```

He probado con otros más imples he incluso hacer downgrade a la versión anterior de zlib, actualizar mozilla-launcher, lanzar revdep-rebuild... pero nada, sigue fallando. Ahora estoy recompilando firefox.

 *Quote:*   

> 
> 
> [I] www-client/mozilla-firefox
> 
>      Available versions:  1.0.7-r4 1.5.0.5 1.5.0.7 [M]2.0_rc2
> ...

 

Funcionaba perfectamente hasta que actualice zlib, esto me pasó hace unas semanas en un portátil, pero en aquel caso no arreglé yo el problema y ahora ando algo perdido con esto para conseguir solucionarlo rápido.

 *Quote:*   

> 
> 
> [U] sys-libs/zlib
> 
>      Available versions:  1.2.3 1.2.3-r1
> ...

 

¿Alguna idea?

un saludo y gracias en cualquier caso.

---

P.D.: en principio el SIGSEV no se debe a ninguna vulnerabilidad explotable que sea grave supongo y/o relacionada con zlib supongo.Last edited by jmp_ on Fri Oct 13, 2006 4:51 pm; edited 9 times in total

----------

## jmp_

Ya me lo han solventado,

Hay que compilar zlib SIN -fomit-frame-pointer y ya no da segfault.

saludos.

----------

## YosWinK

 *jmp_ wrote:*   

> 
> 
> Mis CFLAGS Flags:
> 
> ```
> ...

 

Espero que hayas leido el artículo sobre CFLAGS existente en el gwn de esta semana y te replantees el uso de esas CFLAGS.

To r1c3 or not to r1c3 ... nice question  :Wink: 

----------

## jmp_

He leído mucho sobre CFLAGS, los mios me van perfectamente, salvo ocasiones MUY puntuales.

De hecho esos flags no son de mi máquina, en la de casa tengo un AMD64 aunque con flags similares (usando -O3). Pero bueno, son cosas a tener en cuenta, no obstante ya se ha comentado todo eso con anterioridad. Otro buen recurso es leerse las páginas de GCC sobre optimización, etc.

También es cierto que en muchos casos las optimizaciones tienen especial sentido cuando el programador las usa en su código, pero bueno... de momento no he tenido muchos problemas en cualquier caso si que es cierto que se invierte un poco más de tiempo al compilar, que quizás no sea necesario en muchos casos, sobre todo para máquinas de escritorio.

```

GNU gdb 6.5

Copyright (C) 2006 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are

welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "i686-pc-linux-gnu"...(no debugging symbols found)

Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run

Starting program: /usr/lib/mozilla-firefox/firefox-bin

(no debugging symbols found)

(no debugging symbols found)

(no debugging symbols found)

(no debugging symbols found)

(no debugging symbols found)

(no debugging symbols found)

(no debugging symbols found)

(no debugging symbols found)

[Thread debugging using libthread_db enabled]

[New Thread -1221084432 (LWP 18515)]

[New Thread -1222526048 (LWP 18523)]

[New Thread -1240441952 (LWP 18560)]

[New Thread -1254655072 (LWP 18573)]

Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread -1221084432 (LWP 18515)]

0xb7470927 in inflateBack () from /lib/libz.so.1

(gdb) q

The program is running.  Exit anyway? (y or n) y

```

El problema estaba en que zlib es especialmente sensible a -fomit-frame-pointer almenos ahora ya que antes no he tenido problemas, puede ser al actualizar GCC u otros motivos. En cualquier caso quitando el flag del make.conf se soluciona y el resto de cosas han compilado bien casi siempre.

En cambio, en el NewsLetter no mencionan nada sobre que -fomit-frame-pointer tienda a hacer que muchos programas (como zlib) tengan comportamientos extraños y después fallen (sigsev) pese a compilar bien. Es muy probable que sea más peligroso -fomit-frame-pointer que -ftree-vectorize.

saludos.

----------

## gringo

Realmente lo de añadir cosas de estas globalmente es una chorrada, ftracer o fweb p.ej. están filtrados en un huevo de ebuilds si mal no recuerdo. Pasa lo mismo que con -O3 o -Os, hay unos cuantos ebuilds que fuerzan -O2.

saluetes

----------

## jmp_

No tantos, en mi caso salvo cosas "críticas", la mayoría me compila com mis flags.

La gente de Gentoo son un poco tajantes con el asunto de las optimizaciones y los flags de GCC, si estan es para usarlos no se han programado para que todo se vuelva inestable sino para mejorar. Si los desarrolladores de Gentoo se han currado una buena distribución y no dicen las cosas porque si, de igual forma, la gente que mejora e implementa GCC (que es un compilador potente) sabe perfectamente lo que hace.

No pasa nada por usar -O3 ni flags como -fweb o -ftracer, al menos no más que usar -fomit-frame-pointer o el pack que se incluye al introducir -O2.

----------

## gringo

en mi opinión no pasa nada siempre y cuando:

- está implementado

- sabes lo que estás haciendo

como no creo que esas condiciones se den en todos los ebuilds del árbol ni todos lo usuarios saben lo que hacen, donde por supuesto me incluyo, y además luego ves que por la razón x está filtrado en esa aplicación que tanto usas, tiene sentido juguetear con esto, sobre todo globalmente ? 

No me entiendas mal, soy el primer ricer que se lía con alguna de estas cosillas si creo que puede haber alguna mínima mejora de rendimiento, pero hace tiempo que me he dado cuenta que juguetear con los flags en gentoo no me aporta nada. Eso se lo dejo a los gurús  :Wink: 

saluetes

----------

## jmp_

 *Quote:*   

> como no creo que esas condiciones se den en todos los ebuilds del árbol ni todos lo usuarios saben lo que hacen, donde por supuesto me incluyo, y además luego ves que por la razón x está filtrado en esa aplicación que tanto usas, tiene sentido juguetear con esto, sobre todo globalmente ?
> 
> 

 

Si que tiene sentido, por lo general los flags que pones son los que se aplican. De hecho una de las ventajas de Gentoo es la posbilidad de "tunear" tu make.conf y los CFLAGS como quieras de forma cómoda y globalizada.

 *Quote:*   

> 
> 
> en mi opinión no pasa nada siempre y cuando:
> 
> - está implementado
> ...

 

En este caso está implementado y no me ha dado problemas usar esos flags salvo de manera puntual y obvia. Por lo que compilar con flags menos "sofisticados" para un ebuild concreto no supone un problema.

Efectivamente, la mejora en muchos casos no es extrema... pero vaya, se nota. El cambio que yo haria sería poner -O2 en lugar de -O3 según las prefrencias de cada uno... pero vaya, que por ponerlos no pasa nada que para eso están.

saludos.

----------

## YosWinK

 *jmp_ wrote:*   

> ... pero vaya, que por ponerlos no pasa nada que para eso están.

 

"no pasa nada" ... entre comillas. Pasa lo que te ha sucedido en esta ocasión (cuando no cosas más extrañas) que te encuentras problemas totalmente inexperados que son causa de compilar una dependencia de una aplicación con unas CFLAGS agresivas. ¿Cuantas veces te va a suceder esto? pues, quizá no muchas, pero a mí no me gustaría arriesgarme a tener que depurar un error sin el soporte de tu propia distribución, porque, como supongo que conoces , lo primero que te van a indicar en bugs.gentoo.org cuando vean tus CFLAGS es que recompiles tu sistema entero.

Gentoo se adapta a cada uno, y está bien elegir (en parte) el camino hacia el lado oscuro pero ojo, que hay que pagar un precio.

----------

## jmp_

Lo que me ha pasado esta vez, como has leído, no es por culpa de un flag "no recomendado" por Gentoo.

O sea, que el -fomit-frame-pointer entra dentro del pack "Safe CFLags" y como ves es una de las causas más habituales que provocan errores del tipo que se ha tratado aquí. El resto de flags no influyen pero mejoran y optimizan el código sin romperlo... almenos en la zlib como ha quedado claro.

El -fomit-frame-pointer, "flag seguro" hace el código más difícil de depurar aunque en arquitecturas como AMD64 no hace falta habilitarlo si metes -O2 o -O3 (creo que se integra ya) y no influye negativamente en esos casos almenos en ese sentido, en cambio en el típico athlon-xp o Intel i386 (32bits) si afecta más.

saludos.

----------

## YosWinK

 *jmp_ wrote:*   

> Lo que me ha pasado esta vez, como has leído, no es por culpa de un flag "no recomendado" por Gentoo.

 

Ya solamente por curiosidad y, disculpa la molestia, ¿podría ver el informe del fallo o el hilo del foro donde se trata el asunto y se considera que es culpa de fomit-frame-pointers?

 *jmp_ wrote:*   

> 
> 
> O sea, que el -fomit-frame-pointer entra dentro del pack "Safe CFLags" y como ves es una de las causas más habituales que provocan errores del tipo que se ha tratado aquí. El resto de flags no influyen pero mejoran y optimizan el código sin romperlo... almenos en la zlib como ha quedado claro.
> 
> 

 

Emm ... las personas dentro de Gentoo que tratan con este tipo de fallos son la gente de toolchain, seguramente donde mayor nivel técnico puedes encontrar en Gentoo, creo que ninguno de ellos dejaría que se publicara en gwn un artículo recomendando su uso si luego van a recibir errores por culpa de esto. Sobre "es una de las causas más habituales" creo que no es del todo cierto que -fomit-frame-pointer sea una de las causas más habituales, pero bueno, todo es discutible.

Sobre el resto (o almenos algunas) CFLAGS de tu lista, podemos buscar ejemplos de cómo rompen el código bajo determinadas circunstancias, no siempre.

 *jmp_ wrote:*   

> 
> 
> El -fomit-frame-pointer, "flag seguro" hace el código más difícil de depurar aunque en arquitecturas como AMD64 no hace falta habilitarlo si metes -O2 o -O3 (creo que se integra ya) y no influye negativamente en esos casos almenos en ese sentido, en cambio en el típico athlon-xp o Intel i386 (32bits) si afecta más.
> 
> 

 

Efectivamente afecta a la depuración, y creo, si no meto mucho la zarpa, que en x86 no se habilita a menos que se especifique lo contrario mientras que en amd64 sucede justo a la inversa (con todos los niveles de depuración, -O -O2 -O3 -Os).

----------

## ekz

Entonces, sacamos o no -fomit-frame-pointer del make.conf?

ya que ahora portage avisa de que puede romper algo

----------

## jmp_

 *Quote:*   

> 
> 
> Ya solamente por curiosidad y, disculpa la molestia, ¿podría ver el informe del fallo o el hilo del foro donde se trata el asunto y se considera que es culpa de fomit-frame-pointers? 

 

Está un poco más arriba, tienes una salida del GBD depurando el programa (firefox, que peta por zlib), como te digo -fomit-frame-pointer suele ser la causa de este tipo de SEGFAULTS y otros errores en algunos programas, al recompilar zlib sin el -fomit-frame-pointer Firefox funcionó correctamente.

 *Quote:*   

> 
> 
> Efectivamente afecta a la depuración, y creo, si no meto mucho la zarpa, que en x86 no se habilita a menos que se especifique lo contrario mientras que en amd64 sucede justo a la inversa (con todos los niveles de depuración, -O -O2 -O3 -Os).

 

Creo que es lo que he dicho o almenos eso quería decir. Efectivamente y si nadie lo corrige es así :)

 *Quote:*   

> 
> 
> Entonces, sacamos o no -fomit-frame-pointer del make.conf?
> 
> ya que ahora portage avisa de que puede romper algo

 

Si quieres asegurarte de poner unos flags más conservadores o eres un desarrollador que necesita depurar mucho código de forma habitual no lo pongas, si quieres algo más de optimización no es mala idea. Al fin y al cabo lo puedes habilitar o deshabilitar si ves que con algún programa tienes problemas y recompilarlo con otros adecuados.

saludos.

----------

## YosWinK

 *jmp_ wrote:*   

>  *Quote:*   
> 
> Ya solamente por curiosidad y, disculpa la molestia, ¿podría ver el informe del fallo o el hilo del foro donde se trata el asunto y se considera que es culpa de fomit-frame-pointers?  
> 
> Está un poco más arriba, tienes una salida del GBD depurando el programa (firefox, que peta por zlib), como te digo -fomit-frame-pointer suele ser la causa de este tipo de SEGFAULTS y otros errores en algunos programas, al recompilar zlib sin el -fomit-frame-pointer Firefox funcionó correctamente.
> ...

 

Un par de cosas: efectivamente el error está en zlib pero, ¿no crees que si fuera causa de fomit-frame-pointer, CFLAG que tiene mucha gente en su make.conf, este error habría tenido una repercusión mucho mayor en toda la comunidad? ¿No será que es cosa de las otras CFLAGS, algo muy muy muy parecido a este bug?

----------

## jmp_

Usar -fomit-frame-pointer no tiene porque ser dañino... por usarlo no vas a convertir tu distribución en un caos. Al igual que con los otros flags, pero si es cierto que algunos programas (por el tipo de tarea o como están programados) son más susceptibles a que - pese a compilar bien - el código generado contenga errores que puedan terminar en un segmentation fault.

No creo que el tema sea cuestión de un bug.

saludos.

----------

## LinuxBlues

Quizá debieras recompilar glibc (no olvides el prelink -amhR posterior, si usas prelink); con este parámetro USE   :Arrow: 

 *euse -i glibc-omitfp wrote:*   

> 
> 
> global use flags (searching: glibc-omitfp)
> 
> ************************************************************
> ...

 

El guión entre los corchetes significa que está en mi package.use. No suelo poner uses locales en el make.conf nunca... Como ves, lo que causa es que se use fomit-frame-pointer única y exclusivamente si el sistema lo considera seguro.

Sin comentarios con respecto al resto de tus CFLAGS. Ya sabes que los developers se lavan las manos en cuanto ven algo más que -Ox -march=blah y -fomit-frame-pointer. Parece como si les diera miedo, pero la verdad es que los fallos a los que pueden enfrentarse con unas CFLAGS diferentes a las que se usan en ARCH Linux, sin ir más lejos, debe causarles mucho trabajo   :Rolling Eyes: 

----------

## Ferdy

 *Quote:*   

> Ya sabes que los developers se lavan las manos en cuanto ven algo más que -Ox -march=blah y -fomit-frame-pointer

 

Dependiendo de la arquitectura, pero por lo general si. Porque por lo general sabemos lo que hacen. Ya sea mirando el código del compilador, el código generado por el compilador o porque estudiamos en su momento sobre compiladores. Es lo que tiene...

- ferdy

----------

## LinuxBlues

 *Ferdy wrote:*   

> Es lo que tiene...

 

Cuidado porque debeis estar muy al día, y eso no es fácilmente demostrable...

GCC hace su trabajo y el manual indica todas y cada una de las CFLAGS que pueden ocasionar problemas. A mí, y perdonad por ello, me ha dado por usar Gentoo como conejillo de indias últimamente y fundamentalmente quería aprovechar a tope las SSE. mfpmath=sse (mucho cuidado no 387,sse) no ha causado demasiados quebraderos de cabeza, aunque no terminaría de recomendarlo, porque en principio es imposible saber qué programa espera temporales de 80bit de precisión. Eso sí, ahora juego en una jaula chroot para experimentar y msseregparm (que exige un emerge -e world) peta miserablemente, pero no porque GCC esté haciendo algo inadecuado, sino porque el programa es incapaz de usar los registros SSE y que un sólo programa o librería falle, hace imposible usar esa CFLAG, ¿sería cuestión de actualizar el software (el programa que peta al ser compilado con ella)? Probablemente, pero lo dudo.

La cosa está clara, si se quiere tener un sistema estable, las safe-cflags... y si se quiere experimentar: jaula chroot.

Ferdy: ya lo he dicho, pero insisto  *LinuxBlues wrote:*   

> pero la verdad es que los fallos a los que pueden enfrentarse con unas CFLAGS diferentes a las que se usan en ARCH Linux, sin ir más lejos, debe causarles mucho trabajo

 .

Más claro, agua.

----------

## pacho2

[quote="LinuxBlues"]Ya sabes que los developers se lavan las manos en cuanto ven algo más que -Ox -march=blah y -fomit-frame-pointer. [/code]

¿cómo? ¿dónde ves que se "laven las manos"? No creo que cueste demasiado enviar un reporte de bug solicitando que filtren ese FLAG :-/

Basta que mires la cantidad de ebuilds en el que han filtrado algunos CFLAGS que consideran "peligrosos" :-/

De todos modos yo uso -fomit-frame-pointer y no he tenido ese problema :-/, ¿no será por usar también CFLAGS como -ftracer -fweb -ftree-vectorize...? Quizás deberías probar quitando algunas de ellas y conservando el -fomit-frame-pointer a ver si acotas el problema :-/

Yo llevo usando en mi portátil los siguientes CFLAGS en un Centrino sin ningún problema:

```
-O2 -march=pentium-m -msse3 -mfpmath=sse -fomit-frame-pointer -pipe
```

----------

## Ferdy

 *Quote:*   

> Cuidado porque debeis estar muy al día, y eso no es fácilmente demostrable... 

 

Es parte del trabajo en Gentoo de algunos desarrolladores.. no lo veo tan raro.

 *Quote:*   

> Eso sí, ahora juego en una jaula chroot para experimentar y msseregparm (que exige un emerge -e world) peta miserablemente, pero no porque GCC esté haciendo algo inadecuado, sino porque el programa es incapaz de usar los registros SSE y que un sólo programa o librería falle, hace imposible usar esa CFLAG, ¿sería cuestión de actualizar el software (el programa que peta al ser compilado con ella)? Probablemente, pero lo dudo. 

 

Je... es que cambiar el 'calling convention' no es moco de pavo. Las arquitecturas no-estúpidas llevan pasando los parámetros en registros desde antes de que se inventara la cocacola  :Smile: 

- ferdy

----------

## LinuxBlues

 *Ferdy wrote:*   

> Je... es que cambiar el 'calling convention' no es moco de pavo. Las arquitecturas no-estúpidas llevan pasando los parámetros en registros desde antes de que se inventara la cocacola

 

¿Y cómo piensas que debería sacarle partido a la experiencia?

Si envío un bug al bugzilla de Gentoo me dirán que es una unsupported flag y que la quite, como ya me pasó en otra ocasión 

que precisamente tú mencionaste en estos foros. (Con ello respondo a la primera pregunta de pacho2).

Si envío el bug upstream huy, huy, huy, me meteré en líos porque el programa que peta es groff nada menos (el décimo en un emerge -e world afortunadamente). Y mandar bugs a gnu es algo que no estoy muy por la labor (por todo lo que les debo).

No se puede filtrar la CFLAG como dice pacho2 porque o la usas con todo o te cargas el sistema, como se indica en el man, esto es, que si se filtra se debe filtrar para todo el sistema   :Crying or Very sad:  (y no le veo ningún sentido).

¿Alguna sugerencia para resolver esto? De verdad que enviar bugs a gnu está por encima de mí, por el enorme grado de respeto que les tengo, pero si no queda otra...

Lamento, jmp_ haber conducido completamente off-topic tu pregunta, espero que mi idea de añadir la USE flag glibc-omitfp a glibc te haya servido de ayuda aunque acabo de compilar zlib sin el más mínimo problema con el fomit-frame-pointer y no petan la gran mayoría de los programas que dependen de ella (me refiero a que no he probado todos, porque los resultados de un equery depends zlib echan para atrás...).

Por cierto Ferdy, en tu opinión ¿los amd64 forman parte de esas "arquitecturas no-estúpidas" o siguen siendo una arquitectura estúpida? (el hecho de que no usen msseregparm por defecto me ha dejado con la duda).

----------

## Ferdy

 *Quote:*   

> ¿Y cómo piensas que debería sacarle partido a la experiencia? 

 

Bueno... es complicado... intuyo que habría que ver POR QUÉ se 'rompen' esos programas e intentar arreglarlos si es que es posible.

Si realmente es un bug, da igual que lo reportes a GNU o a la Madre de Dios, es un bug.

 *Quote:*   

> Por cierto Ferdy, en tu opinión ¿los amd64 forman parte de esas "arquitecturas no-estúpidas" o siguen siendo una arquitectura estúpida? (el hecho de que no usen msseregparm por defecto me ha dejado con la duda).

 

No es algo opinable, los 'calling conventions' son unos y no dependen de mi opinión. El hecho es que, en x86_64, los cuatro primeros parámetros se pasan en registros, el resto en la pila.

- ferdy

----------

## pacho2

[quote="LinuxBlues"]

```

Si envío un bug al bugzilla de Gentoo me dirán que es una unsupported flag y que la quite, como ya me pasó en otra ocasión 

que precisamente tú mencionaste en estos foros. (Con ello respondo a la primera pregunta de [b]pacho2[/b]).
```

Puedes tomar por ejemplo el ebuild de wesnoth-1.1.11, allí filtran determinados CFLAGS agresivos.

```

Si envío el bug upstream huy, huy, huy, me meteré en líos porque el programa que peta es groff nada menos (el décimo en un emerge -e world afortunadamente). Y mandar bugs a gnu es algo que no estoy muy por la labor (por todo lo que les debo).
```

¿qué te ha pasado exactamente con groff? ¿qué CFLAG le has intentado pasar?

```
No se puede filtrar la CFLAG como dice [b]pacho2[/b] porque o la usas con todo o te cargas el sistema, como se indica en el man, esto es, que si se filtra se debe filtrar para todo el sistema  :cry: (y no le veo ningún sentido).
```

Lo acabo de comentar

```

Lamento, [b]jmp_[/b] haber conducido completamente off-topic tu pregunta, espero que mi idea de añadir la USE flag [i]glibc-omitfp[/i] a glibc te haya servido de ayuda aunque acabo de compilar zlib sin el más mínimo problema con el fomit-frame-pointer y no petan la gran mayoría de los programas que dependen de ella (me refiero a que no he probado todos, porque los resultados de un [i]equery depends zlib[/i] echan para atrás...).
```

Precisamente esos "gandules" de bugs.gentoo.org ya saben que CFLAG es el que da los problemas, si tienes ánimo de conocer un poco más pásate por 

```
http://bugs.gentoo.org/show_bug.cgi?id=151394
```

Aunque tengo mis dudas de que lo hagas, porque a veces pienso que sólo intentas buscar problemas en gentoo, no para que los solucionen, simplemente por criticar destructivamente y para montar bronca

Saludos

PD: Bronca que, he de admitir, a veces resulta hasta entretenida  :Razz: 

----------

## LinuxBlues

 *pacho2 wrote:*   

> Aunque tengo mis dudas de que lo hagas, porque a veces pienso que sólo intentas buscar problemas en gentoo, no para que los solucionen, simplemente por criticar destructivamente y para montar bronca

 

te equivocas, jamás pretendieron ser destructivas, muestro errores admito que quizá con crudeza, pero por el amargo sabor de boca que me producían con Gentoo; juro que a pesar de ello siempre pretendieron ser constructivas, que alguien las viese y dijese, esto está de pena, pero nunca ocurrió, aunque bugzilla ya tiene demasiadas muestras de ello, el bug de openoffice-2.0.3 sin el cual no puedo trabajar, sin ir más lejos ... y al que no le han hecho ni puto caso... Yo no puedo andar con una distro así, o con una distro que un día te actualiza glibc y con la que no puedes meter passwords con acentos... y cuando digo que no puedo me refiero a que sí que puedo, pero si lo hago pierdo dinero ¿lo entiendes pacho2?

----------

## YosWinK

 *LinuxBlues wrote:*   

> 
> 
> Lamento, jmp_ haber conducido completamente off-topic tu pregunta, espero que mi idea de añadir la USE flag glibc-omitfp a glibc te haya servido de ayuda aunque acabo de compilar zlib sin el más mínimo problema con el fomit-frame-pointer y no petan la gran mayoría de los programas que dependen de ella (me refiero a que no he probado todos, porque los resultados de un equery depends zlib echan para atrás...).
> 
> 

 

La USE glibc-omitfp activa --enable-omitfp sobre la que podemos conocer, según los propios desarrolladores de glibc:

"We recommend against this. The extra optimization doesn't gain you much, it may provoke compiler bugs, and you won't be able to trace bugs through the C library." 

Pero bueno, supongo que si se la has recomendado tus motivos tendrás, yo personalmente no la conocía. 

 *LinuxBlues wrote:*   

> 
> 
>  Yo no puedo andar con una distro así, o con una distro que un día te actualiza glibc y con la que no puedes meter passwords con acentos... y cuando digo que no puedo me refiero a que sí que puedo, pero si lo hago pierdo dinero
> 
> 

 

Por curiosidad, he cambiado un password y le he puesto un carácter con "tilde". He respirado tranquilo cuando he visto que está característica fundamental de mi sistema ha funcionado como siempre  :Wink:  No seamos exagerados, por favor. 

En cuanto a lo de perder dinero, LinuxBlues, ya te lo dijimos en su momento:

Depende del tipo de administración o gestión de tu sistema que lleves con Gentoo. ¿Que hay bugs? Los hay. ¿Que tardan en solucionarse? Muchas veces sí ¿Que te ocasionan molestias? y a mí ¿Que los podrías solucionar tú si tuvieras los conocimientos suficientes? sin duda y mandar un parche ¿cuanto pagas por el soporte de Gentoo y caso que te hacen sus desarrolladores? cero, esto no es una distribución comercial. ¿Puedes pagar para que te vaya mejor la cosa? En red-hat ¿Allí tienen foros? Seguro que sí ¿Resuelven los bugs en cuanto tú se los mandas? lo dudo ¿Te hacen más caso sus desarrolladores que en gentoo? lo dudo también.

----------

## LinuxBlues

 *YosWinK wrote:*   

> 
> 
> La USE glibc-omitfp activa --enable-omitfp sobre la que podemos conocer, según los propios desarrolladores de glibc:
> 
> "We recommend against this. The extra optimization doesn't gain you much, it may provoke compiler bugs, and you won't be able to trace bugs through the C library." 
> ...

 

¿Quiere ello decir que la descripción: "Configure glibc with --enable-omitfp which lets the build system determine when it is safe to use -fomit-frame-pointer" es una completa tontería?

 *YosWinK wrote:*   

> 
> 
> Por curiosidad, he cambiado un password y le he puesto un carácter con "tilde". He respirado tranquilo cuando he visto que está característica fundamental de mi sistema ha funcionado como siempre  No seamos exagerados, por favor. 
> 
> 

 

En el mismo sistema no hay problema, mi problema fué con glibc-2.3.6-r3 (si mal no recuerdo), y la cuestión esque aunque teclees un carácter que no aparece en la terminal (al escribir una vocal con acento), en realidad le estás pasando un carácter, si pulsas enter te aparece bash: : command not found. Ahora prueba como en mi caso, a hacer login remoto en un servidor que estés administrando (RHEL en mi caso y un servidor que no es mío sino de la empresa). Mis acentos o tildes no estaban sobre vocales, además, sino sobre consonantes... Tú prueba y verás, ¿qué ocurre?   :Arrow: 

 *YosWinK wrote:*   

> 
> 
> En cuanto a lo de perder dinero, LinuxBlues, ya te lo dijimos en su momento:
> 
> 

 

Pues eso precisamente, que eres incapaz de hacer login en el servidor que administras, lo segundo son efectos secundarios.

 *YosWinK wrote:*   

> 
> 
> Depende del tipo de administración o gestión de tu sistema que lleves con Gentoo. ¿Que hay bugs? Los hay. ¿Que tardan en solucionarse? Muchas veces sí ¿Que te ocasionan molestias? y a mí ¿Que los podrías solucionar tú si tuvieras los conocimientos suficientes? sin duda y mandar un parche ¿cuanto pagas por el soporte de Gentoo y caso que te hacen sus desarrolladores? cero, esto no es una distribución comercial. ¿Puedes pagar para que te vaya mejor la cosa? En red-hat ¿Allí tienen foros? Seguro que sí ¿Resuelven los bugs en cuanto tú se los mandas? lo dudo ¿Te hacen más caso sus desarrolladores que en gentoo? lo dudo también.

 

Sólo decir que tengo los conocimientos suficientes como para realizar mi trabajo a la perfección (siempre y cuando no me tope con problemas software inesperados e inimaginables y por tanto irresolubles). Mi trabajo, no consiste en mantener una distribución ni resolver sus problemas, os admiro a todos por ello, pero rechazo el carácter no sólo de bastantes desarrolladores que no sé qué se creen, sino el de sus respuestas (¿qué demonios, yo tan sólo estaba intentando informar de un problema que me encontré, por qué me tratas así? Ya sabes que esto ha sido tratado en más de una ocasión en vuestras listas... Ya no uso el bugzilla de gentoo, pero estoy seguro de que te siguen tratando ... digamos ... del mismo modo en que lo han hecho siempre. No puedo evitar que me parezca una forma de responder típica de un maleducado, aunque he de admitir que quizá sea demasiado subjetivo. Pero recibir ese tipo de respuestas en bugzilla es como decir, para que me tiren un jarro de agua fría mejor me callo... ¿Piensas que pagar cero hace posible eso? No tengo idea de cómo será la cosa en debian, pero peor seguro que no. Los foros, si los hibiese en red hat, serían para mí lo mismo que los de gentoo o los de arch linux: algo para pasar el rato, algo que es mejor no tomarse muy en serio: un simple entretenimiento. En red hat no se necesitan foros, algo que sugeriste hace tiempo, eso de llevar toda la documentación que se encuentra presente en este a un subforo, pues algo así es lo que han hecho ellos: http://kbase.redhat.com/faq/  Échale un vistazo, si realmente hay algo que no se responda allí entonces es cuando recurres al servicio técnico, pero no lo he necesitado hasta ahora, en parte debido a todo lo que gentoo, como un LFS, me ha hecho aprender, peeeeeero ¿necesito yo saber todo eso o he estado perdiendo el tiempo? Pues lo segundo, yo sólo necesito cumplir con mi trabajo y no soy informático. Meterme en los entresijos de todos los programas que formaban parte de mi world ha sido divertido y un hobby, aunque poco razonable. Disculpa si estoy siendo excesivamente práctico como para que lo entiendas...

 *pacho2 wrote:*   

> ¿qué te ha pasado exactamente con groff? ¿qué CFLAG le has intentado pasar?

 

-msseregparm

¿Podrías intentar compilarlo con tus cflags más -msseregparm? si no tienes entorno chroot de pruebas, por favor usa un emerge -B groff únicamente, como ya decía, y como el manual de gcc dice, si usas -msseregparm debes hacerlo con absolutamente todo el sistema o te lo cargarás. ¡Ah! no olvides quitar msseregparm después, creo que estoy dejando bien claro porqué...

Gracias.

Editado: pacho2, a propósito, ¿cómo editas tus posts? ¿con el php tal cual?, ¡qué cosas!

----------

## pacho2

 *LinuxBlues wrote:*   

> 
> 
> Editado: pacho2, a propósito, ¿cómo editas tus posts? ¿con el php tal cual?, ¡qué cosas!

 

 :Shocked:  , no sé a qué te refieres  :Sad: 

----------

## LinuxBlues

 *pacho2 wrote:*   

>  , no sé a qué te refieres 

 

A ésto. El [quote="yomismo"] del principio ya canta, pero los [ b] [ /b] en las citas es lo que me ha llevado a hacerte la pregunta...

----------

## pacho2

Es lo que tiene editarlos rápidamente  :Very Happy: 

aunque tampoco es para tanto ¬¬

----------

## Ferdy

Es que utilizar passwords para hacer login en un servidor remoto es penoso. Así que aunque quizá hubiera tal problema (a mi no me ha pasado en ningún momento, quizá porque no se me ocurre usar passwords para entrar en mis máquinas), la consecuencia real es solo culpa tuya.

- ferdy

----------

## LinuxBlues

 *Ferdy wrote:*   

> Es que utilizar passwords para hacer login en un servidor remoto es penoso. Así que aunque quizá hubiera tal problema (a mi no me ha pasado en ningún momento, quizá porque no se me ocurre usar passwords para entrar en mis máquinas), la consecuencia real es solo culpa tuya.

 

Sí hombre, pues claro que fue culpa mía ¿de quién iba a ser si no?

En cuanto a lo de administrador, tú hablas de "tus" equipos. Que yo administre ciertos aspectos de un servidor no significa que yo sea root, ni que sea "mi" equipo en este caso. Estoy hablando de un servidor al que es como si le hubiesen hecho un userdel root. Imagínatelo: es como si hubiese grupos de administración. No se puede hacer login directamente como (uno de los) administrador(es), aunque autentique con los MAC a los usuarios normales no basta con ello: es necesaria la contraseña porque cualquiera podría coger mi portátil o cualquier otro equipo; todos los que estamos en el grupo de administración tenemos imposibilitado el acceso debido al usertty y como usuarios normales tenemos posibilidad de entrar aunque con muchas otras restricciones. Por tanto sólo puedes hacer login como usuario "normal" y su - administradorX, ¿me quieres decir como evitas las contraseñas en este caso?

Esa máquina no la administra una sola persona: "administradorX" tiene permisos sólo sobre ciertos ficheros (o aspectos) muy concretos y no puede tocar los de "administradorY".

No siempre que leas administrador tengas a un root o a una única persona en la cabeza. ¿No te ha dado por pensar en ello? De todo lo que te estoy contando se encargó un informático, ¿qué rama estás estudiando tú?, el que hizo todo esto era de sistemas y tampoco es que sea un tipo brillante (todo hay que decirlo), por lo que presupuse que todo esto de la administración múltiple, lo habría visto en la Universidad. Ferdy, ese día no fuiste a clase, ¿verdad?

A mí sinceramente me sorprendió también mucho que no se pudiese entrar directamente como administradorX, administradorY... pero tiene sus motivos, te lo aseguro.

Efectivamente la culpa fue mía por usar el generador de claves aleatorias y por usar una con tildes en consonantes que supongo deberán existir en cualquier otro idioma. Era, a pesar de todo, fácil de recordar (quizá por rara) y me la quedé, con las consecuencias expuestas... Pude hacer login con Gentoo y esa clave muchas veces, hasta que un día dejé de poder hacerlo tras actualizar glibc: la actualización era de release únicamente y ya sabes lo que -r4 significa en el nombre de un ebuild mejor que yo, ¿no? (para quien no lo sepa: que la modificación ha sido realizada únicamente por los desarrolladores de Gentoo). De hecho ahora con la versión 2.4-r3 vuelvo a tener tildes, eñes y diéresis (ü) en el desktop. Que no era como para crucificar Gentoo y mostrar todo mi desencanto en los foros como he hecho, es probable. Sobre todo porque Gentoo me hizo darme cuenta de que mi portátil era algo más que una herramienta de trabajo, lo era también de administración y no podía seguirme permitiendo jugar con él, tal y como había estado haciendo.

Para que veas lo que son las cosas, sigo empleando el mismo password (con RedHat): que contiene una ś y me he dado cuenta de que tecleada en la terminal aparece como: 's y el caso fue que Gentoo no devolvía aparentemente nada, era como un carácter nulo, pero si pulsabas enter, en fin, ya lo he dicho, aparecía bash: : command not found. Las contraseñas jamás pueden leerse. Es probable que sea 's en lugar de ś en realidad. Pero ese problema puntual, porque fue puntual me hizo mucho la puñeta.

A propósito, Ferdy, ¿qué demonios dijiste de que era culpa del kernel? Vuelvo a tener todos los caracteres mencionados sin el más mínimo problema. Tal y como los tuve con anterioridad a esa release concreta de glibc. ¿Tenías presente que se incluyen todos ellos (acentos, eñes y la üÜ) en latin1 (iso-8859-1) o no? Tú también dices alguna que otra tontería de vez en cuando, como ves. En esta ocasión, además has hablado desconociendo de lo que hablabas, ademásç, como si yo hubiese sido el único administrador de la máquina en cuestión.

----------

## pacho2

Yo de momento con la glibc que ahora está en estable y las gentoo-sources-2.6.18-r1 tengo acentos en las consolas y me van perfectamente, además tengo en UTF-8 tanto las consolas como las X.

Saludos  :Smile: 

----------

## Ferdy

 *Quote:*   

> snip tochazo sobre como administrais un servidor

 

Sigue siendo penoso utilizar passwords para hacer login. Si el sistema que usais para administrar esa máquina obliga a que utiliceis passwors, el sistema es penoso. ¿Qué no entiendes? 

En mi trabajo tambien tenemos muchos servidores que administra mucha gente... y curiosamente todo funciona bien y nadie tiene que enredar con passwords.

Y si.. a clase de criptografía y seguridad si fui, de ahí que mantenga mi argumento de que es PENOSO que tengas que usar passwords para hacer login.

 *Quote:*   

> A propósito, Ferdy, ¿qué demonios dijiste de que era culpa del kernel? Vuelvo a tener todos los caracteres mencionados sin el más mínimo problema. Tal y como los tuve con anterioridad a esa release concreta de glibc. ¿Tenías presente que se incluyen todos ellos (acentos, eñes y la üÜ) en latin1 (iso-8859-1) o no? Tú también dices alguna que otra tontería de vez en cuando, como ves. En esta ocasión, además has hablado desconociendo de lo que hablabas, ademásç, como si yo hubiese sido el único administrador de la máquina en cuestión.

 

Lee la lkml y deja de hacer perder el tiempo a la gente leyendo chorradas. (Si no recuerdo mal los parches entraron en los últimos kernel.... ni idea, me interesa muy poquito).

- ferdy

----------

## YosWinK

Señores:

Es hora de parar, que bastante off-topic le hemos puesto entre todos al tema. Las discusiones / decisiones sobre como administrar cada uno su servidor son infinitas.

No more, thanks.

----------

