On Sat, Nov 18, 2006 at 12:08:19AM -0600, Luis Rodrigo Gallardo Cruz wrote:
> Pero, esos errores los está generando vmware que al parecer fué
> compilado con gcc 4.2 y, por lo tanto, está tratando de cargar
> bibliotecas para 4.2. Y no fué nadie en Debian quien compiló así el
> vmware, fué la gente de vmware.

Y ya que me puse a jugar un rato con objdump, estoy empezando a pensar
que el error no va por ahí. Me falta mucho que entender sobre
bibliotecas dinámicas y versiones, pero:

> > (vmware:7295): libgnomevfs-WARNING **: Cannot load module
> > `/usr/lib/gnome-vfs-2. 0/modules/libfile.so'
> > (/usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0'
> > not found (required by /usr/lib/libstdc++.so.6))

Ahí parece decir que no puede cargar
 (1) /usr/lib/gnome-vfs-2.0/modules/libfile.so
pero que el error viene de
 (2) /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1
Si estoy entendiendo bien, lo que pasa es que
 (3) /usr/lib/libstdc++.so.6
quiere que (2) tenga una versión GCC_4.2.0

Veamos objdump -p (3):
...
Version References:
 ...
  required from libgcc_s.so.1:
    0x0b792653 0x00 21 GCC_3.3
    0x09276060 0x00 19 GCC_4.2.0    <-------------- Sí
    0x0b792650 0x00 17 GCC_3.0
    0x0d696910 0x00 13 GLIBC_2.0

Obviamente Debian no incluye (2). Pero sí incluye una
 (4) /lib/libgcc_s.so.1
de nombre sospechosamente parecido. Y además

$ ldd /usr/lib/libstdc++.so.6
        linux-gate.so.1 =>  (0xffffe000)
        libm.so.6 => /lib/tls/libm.so.6 (0xb7e78000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7e6d000) <-------- mmmm
        libc.so.6 => /lib/tls/libc.so.6 (0xb7d3b000)
        /lib/ld-linux.so.2 (0x80000000)


objdump -p (4):
...
Definiciones de versión:
1 0x01 0x04bd5c11 libgcc_s.so.1
2 0x00 0x0d696910 GLIBC_2.0
3 0x00 0x0b792650 GCC_3.0
        GLIBC_2.0
4 0x00 0x0b792653 GCC_3.3
        GCC_3.0
5 0x00 0x09265f61 GCC_3.3.1
        GCC_3.3
6 0x00 0x0b792654 GCC_3.4
        GCC_3.3.1
7 0x00 0x09265e62 GCC_3.4.2
        GCC_3.4
8 0x00 0x09275a60 GCC_4.0.0
        GCC_3.4.2
9 0x00 0x09276060 GCC_4.2.0  <------- ¡Ajá!
        GCC_4.0.0


Lo cual dice que, al parecer, libggc_s.so.1 contiene definiciones de
símbolos referentes de algún modo a gcc-4.2.

¿Qué pasa con vmware? Supongo que, por como fue compilado, antes de
intentar cargar (1), el linker ya cargó (2). Así que cuando (1) pide
(3) que a su vez pide libgcc_s.so.1 el linker decide satisfacer la
petición con (2) y nunca busca (4).

¿Qué concluyo de ésto? Que tu vmware no fue compilado con 4.2. Todo lo
contrario, fue compilado con un gcc de cuando 4.2 no existía ni en la
imaginación de los desarrolladores de gcc, o algo así.

Experimento para verificar: ¿Que sale con un objdump -p (2) en tu
sistema? Mi apuesta es que no hay ni una mención a GCC_4.2.0

Experimento 2: Quita (2) (guardala por ahí, no nada más la borres) y
pon en su lugar un vínculo a (4). Esto puede: a) Corregir el problema
o b) hacer que vmware truene como ejote desde el arranque :-).

Supongo que con KDE funciona por que las bibliotecas equivalentes no
hacen nunca referencia a (3), que es la que al parecer genera el
conflicto (Extraña situación, que gnome quiera cosas de c++ para algo
y kde no. De todo hay, en este valle de lágrimas).

Y ya me voy a dormir, que habla muy mal de mí que esté un viernes por
la noche analizando problemas de bibliotecas dinámicas por diversión.

Attachment: signature.asc
Description: Digital signature

Responder a