On 09/08/2010 05:47 PM, Alan McKinnon wrote: > Apparently, though unproven, at 23:19 on Wednesday 08 September 2010, dhk did > opine thusly: > >> On 09/08/2010 09:36 AM, Alan McKinnon wrote: >>> Apparently, though unproven, at 15:11 on Wednesday 08 September 2010, dhk >>> did >>> >>> opine thusly: >>>> Below is the output when I run "revdep-rebuild --ignore". This started >>>> in the spring and never cleared up. Everything on my amd64 box runs >>>> fine and nothing complains about the missing library. I regularly do >>>> updates and everytime I run "revdep-rebuild --ignore" I get the same >>>> results. How can I fix or get rid of this problem? >>>> >>>> # revdep-rebuild --ignore >>>> >>>> * 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 >>>> * Generated new 1_files.rr >>>> * Collecting complete LD_LIBRARY_PATH >>>> * Generated new 2_ldpath.rr >>>> * Checking dynamic linking consistency >>>> >>>> [ 39% ] * broken /usr/lib32/qt4/libQtOpenGL.so.4.6.2 (requires >>>> libGL.so.1) >>> >>> LibGL is normally provided by xorg (or by emul-linux-x86-opengl) for the >>> 32 bit lib on a 64 bits system. >>> >>> In my case, I have this: >>> >>> a...@nazgul ~ $ ls -al /usr/lib32/libGL.so >>> lrwxrwxrwx 1 root root 33 2010-09-01 11:29 /usr/lib32/libGL.so -> >>> opengl/nvidia/lib/libGL.so.256.53 >>> a...@nazgul ~ $ ls -al /usr/lib32/opengl/xorg-x11/lib/libGL.so.1.2 >>> -rwxr-xr-x 1 root root 473556 2010-06-11 11:29 /usr/lib32/opengl/xorg- >>> x11/lib/libGL.so.1.2 >>> a...@nazgul ~ $ ls -al /usr/lib32/opengl/nvidia/lib/libGL.so* >>> lrwxrwxrwx 1 root root 15 2010-09-01 11:29 >>> /usr/lib32/opengl/nvidia/lib/libGL.so -> libGL.so.256.53 >>> lrwxrwxrwx 1 root root 15 2010-09-01 11:29 >>> /usr/lib32/opengl/nvidia/lib/libGL.so.1 -> libGL.so.256.53 >>> -rwxr-xr-x 1 root root 765460 2010-09-01 11:29 >>> /usr/lib32/opengl/nvidia/lib/libGL.so.256.53 >>> >>> >>> I think you need to run "eselect opengl" to fix all your symlinks >> >> I ran the following, but the "revdep-rebuild --ignore" results are the >> same. # eselect opengl list >> Available OpenGL implementations: >> [1] xorg-x11 * >> # eselect opengl set 1 >> Switching to xorg-x11 OpenGL interface... done >> # eselect opengl list >> Available OpenGL implementations: >> [1] xorg-x11 * >> >> I also don't have the following. >> # ls -l /usr/lib32/opengl* >> ls: cannot access /usr/lib32/opengl*: No such file or directory >> # ls -al /usr/lib32/libGL.so >> ls: cannot access /usr/lib32/libGL.so: No such file or directory > > > In that case, I think you need to conclude that emul-linux-x86-qtlibs is > built to link to libGL which you don't have and which you can't fix (it's a > binary package). So you could > > - delete /usr/lib32/qt4/libQtOpenGL.so.4.6.2 as I doubt you are running 32 > bit > Qt apps, or > - use SEARCH_DIRS_MASK to tell revdep-rebuild to just ignore that file > > > >
Well I deleted /usr/lib32/qt4/libQtOpenGL.so.4.6.2 and ran revdep-rebuild and got the following . . . * Checking dynamic linking consistency [ 39% ] * broken /usr/lib32/qt4/plugins/graphicssystems/libqglgraphicssystem.so (requires libQtOpenGL.so.4) [ 100% ] * Generated new 3_broken.rr . . . * All prepared. Starting rebuild emerge --oneshot --jobs=2 --with-bdeps y app-emulation/emul-linux-x86-qtlibs:0 .......... Calculating dependencies... done! After revdep-rebuild finished the library was back. dhk
