[compiz] compiz 0.7 error "No GLXFBConfig for default depth" on nvidia + x86_64

[Colin Guthrie]

Colin Guthrie wrote:
> Can't believe I didn't notice this before, but this only seems to affect
> x86_64 boxes.... Probably a key factor.

OK, we've gotten to the bottom of this now. Two of my fellow Mandriva
bods have worked out what's gone wrong:

J.A. Magallón wrote:
> Hi all...
> 
> I have been diggin around about this problem, and in the nVidia Linux forum
> feel on this post:
> 
> http://www.nvnews.net/vbulletin/showpost.php?p=1577808&postcount=28
> 
> It just says that the bad binary is linked against Mesa libraries instead
> of finding nVidia ones.
> 
> I tried this on the x86-64 box:
> 
> cicely:~# ldd $(which gears) | grep GL
>     libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00002af29d9c9000)
>     libGL.so.1 => /usr/lib64/nvidia-current/libGL.so.1 (0x00002af29dc47000)
>     libGLcore.so.1 => /usr/lib64/nvidia-current/libGLcore.so.1 (0x00002af29f285000)
> cicely:~# ldd $(which compiz) | grep GL
>     libGL.so.1 => /usr/lib64/libGL.so.1 (0x00002abb07a0f000)
> 
> ld.so.conf is correct, so gears finds the correct library, but I don't know why
> compiz has the path hardcoded.
> On a i386 box with exactly the same versions of packages, this gives:
> 
> annwn:~# ldd $(which gears) | grep GL
>     libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7e8e000)
>     libGL.so.1 => /usr/lib/nvidia-current/libGL.so.1 (0xb7dea000)
>     libGLcore.so.1 => /usr/lib/nvidia-current/libGLcore.so.1 (0xb6f21000)
> annwn:~# ldd $(which compiz) | grep GL
>     libGL.so.1 => /usr/lib/nvidia-current/libGL.so.1 (0xb7b8b000)
>     libGLcore.so.1 => /usr/lib/nvidia-current/libGLcore.so.1 (0xb6f33000)
> 
> and obviously it works.
> 
> With readelf:
> 
> annwn:~# readelf -d $(which compiz) | grep PATH
> 
> (no output, no RPATH harcoded)
> 
> on x64:
> 
> cicely:~# readelf -d $(which compiz) | grep PATH
>  0x000000000000000f (RPATH)              Library rpath: [/usr/lib64]
> 
> This looked like some link option -L was turned into a -R or -rpath
> (this is the way I know to fix a RPATH...)
> 
> If this gives a clue...


To which Anssi Hannula replied:
> Yes, wrong RPATH=/usr/lib64 (and RPATH=/lib64 on some binaries). This is
> the same bug that elisa and libSDL had. We really should get a check
> that blocks upload on "RPATH=(/usr)?/lib64".
> 
> I fixed this in 0.7.2-3, by running autoreconf.


So it could be the way the compiz 0.7.2 tarball was generated perhaps?
Anyways, it seems a simple autoreconf fixes things.

Thanks all for their head scratching :) Annoyingly it turned out to be
something quite simple that an LDD would have highlighted fairly
quickly. I'll keep this in the memory bank for future debugging.

Col