# revdep-rebuild y libstdc++.so.5 [Solucionado]

## diegoto

Hago un revdep-rebuild y me dice que tiene que compilar nuevamente los drivers ATI para solucionar un enlace a uan librerias, lo hace y cuando vuelvo a hacer revdep-rebuild me tira denuevo el error.

```

localhost ~ # revdep-rebuild -p

Configuring search environment for revdep-rebuild

Checking reverse dependencies...

Packages containing binaries and libraries broken by a package update

will be emerged.

Collecting system binaries and libraries... done.

  (/root/.revdep-rebuild.1_files)

Collecting complete LD_LIBRARY_PATH... done.

  (/root/.revdep-rebuild.2_ldpath)

Checking dynamic linking consistency...

  broken /usr/lib32/dri/fglrx_dri.so (requires  libstdc++.so.5)

 done.

  (/root/.revdep-rebuild.3_rebuild)

Assigning files to ebuilds... done.

  (/root/.revdep-rebuild.4_ebuilds)

Evaluating package order... done.

  (/root/.revdep-rebuild.5_order)

All prepared. Starting rebuild...

emerge --oneshot -p =x11-drivers/ati-drivers-8.40.4

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R   ] x11-drivers/ati-drivers-8.40.4

Now you can remove -p (or --pretend) from arguments and re-run revdep-rebuild.

```

```

localhost ~ # ldd /usr/lib32/dri/fglrx_dri.so

        linux-gate.so.1 =>  (0xffffe000)

        libm.so.6 => /lib32/libm.so.6 (0xf7674000)

        libstdc++.so.5 => not found

        libpthread.so.0 => /lib32/libpthread.so.0 (0xf765e000)

        librt.so.1 => /lib32/librt.so.1 (0xf7655000)

        libGL.so.1 => //usr/lib32/opengl/ati/lib/libGL.so.1 (0xf75b4000)

        libdl.so.2 => /lib32/libdl.so.2 (0xf75b0000)

        libX11.so.6 => /usr/lib32/libX11.so.6 (0xf74c5000)

        libXext.so.6 => /usr/lib32/libXext.so.6 (0xf74b7000)

        libc.so.6 => /lib32/libc.so.6 (0xf7395000)

        /lib/ld-linux.so.2 (0x56555000)

        libXau.so.6 => /usr/lib32/libXau.so.6 (0xf7391000)

        libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf738c000)

```

```

localhost ~ # locate libstdc++.so.5

/usr/lib64/libstdc++-v3/libstdc++.so.5

/usr/lib64/libstdc++-v3/libstdc++.so.5.0.6

```

Me suena algun problema de 32bits, ya que la libreria esta compilada para 64bits.

----------

## i92guboj

Asumo que estás usando amd64. Algunas preguntas:

1.- ¿Existe /usr/lib32/libstdc++.so.5?

2.- ¿se ha instalado emul-linux-x86-compat?, si es así, dinos que versión del paquete.

Si está instalado, debería estar dicha librería. Si no lo está, quizás deberían añadirlo como dependencia a los drivers de ati. En cualquier caso, no puedo estar seguro, porque no uso dichos drivers. No se si vienen precompilados para 64bits, o si el binario que se usa es el mismo en x86 y amd64.

----------

## diegoto

Lo solucione haciendo lo siguiente:

emerge app-emulation/emul-linux-x86-compat

Saludos y gracias

----------

## i92guboj

 *diegoto wrote:*   

> Lo solucione haciendo lo siguiente:
> 
> emerge app-emulation/emul-linux-x86-compat
> 
> Saludos y gracias

 

Mmmm, hay una cosa que no me explico...

¿Como instalaste los drivers? ¿Usaste emerge o los has instalado a mano?

Acabo de mirar los ebuilds de ati-drivers, y las tres últimas versiones de los mismos incluyen dicho paquete como dependencia, así que no se por qué no lo tienes instalado. A no ser que tengas una versión más antigua que ati-drivers-8.37.6-r1.ebuild. Al parecer las anteriores versiones no llevan dicha dependencia.

----------

## diegoto

Instale con el emerge, solo que utilice la ultima version de ati-drivers que no estan en la rama estable.

```

localhost ~ # equery list ati

[ Searching for package 'ati' in all categories among: ]

 * installed packages

[I--] [ ~] x11-drivers/ati-drivers-8.40.4 (0)

```

----------

## gringo

esto huele a --with-bdeps, no ?

http://www.gentoo.org/proj/en/portage/doc/faq.xml

saluetes

----------

## i92guboj

 *gringo wrote:*   

> esto huele a --with-bdeps, no ?
> 
> http://www.gentoo.org/proj/en/portage/doc/faq.xml
> 
> saluetes

 

No se, yo creo que lo que ha debido pasar será algo más mundano. Como que haya desinstalado el paquete por error o que emergiera ati-drivers con --nodeps. --with-bdeps sirve para actualizar nodos remotos en el árbol de dependencias que por una u otra razón no se actualizan (aunque están instalados) al hacer un emerge -uD world.

Pero en este caso estamos hablando de que faltaba por instalar un paquete que es una dependencia directa de un ebuild que sí que está instalado. Quizás el fallo sea de portage, quizás sea un error humano, no lo se jeje, y ciértamente es muy difícil intuir (y aún más asegurar) que es lo que pasó. Afortunadamente no ha sido difícil de resolver  :Smile: 

----------

## ZaPa

Hola a todos, tengo una preguntita, que hace exactamente el parametro: --with-bdeps .

Saludos.

Muchas gracias.

----------

## i92guboj

 *ZaPa wrote:*   

> Hola a todos, tengo una preguntita, que hace exactamente el parametro: --with-bdeps .
> 
> Saludos.
> 
> Muchas gracias.

 

 *man emerge wrote:*   

> 
> 
>        --with-bdeps < y | n >
> 
>               In dependency calculations, pull in build  time  dependencies  that
> ...

 

Traducción al castellano moderno:

Existen dependencias que se requieren solo mientras se está compilando un paquete, y no están estrictamente requeridas para poder ejecutarlo. Dichos paquetes, normalmente no se incluyen en el árbol de dependencias cuando se realiza una operación masiva como emerge -uDvN world. Es decir, en ese tipo de operaciones, es como si usáramos "--with-bdeps n". Sin embargo, si que se incluyen en operaciones de limpieza, como --depclean (es como si se usara "--with-bdeps y".

Normalmente, no aconsejo añadir "--with-bdeps y" a EMERGE_DEFAULT_OPTS, porque todo el cálculo adicional que supone esto ralentiza de forma considerable el cálculo de dependencias. Además, a lo sumo, podemos tener uno o dos paquetes no actualizados en nuestro sistema, y son solo utilidades puntuales de compilación, que no usamos en el día a día. La mayoría se actualizan igualmente porque si no son dependencia directa de un paquete, normalmente lo son del algún otro.

En cualquier caso, no se trata del caso que nos ocupa con el ebuild de ati-driver.

----------

