Colin Guthrie wrote:
> Steve Morris wrote:
>> Anssi Hannula wrote:
>>> Have you run "ldconfig" after you used update-alternatives to change
>>> the
>>> driver? If not, then do so.
>
>> Anssi,
>>   Yes, I have cold booted the system several times since running the
>> update-alternatives, although having said that I have Modulepath
>> statements in xorg.conf that cause xorg to not use the
>> update-alternatives environment for opengl anyway.
>
> I wasn't aware that ldconfig was run at boot. I can only assume you
> think it is as you mentioned cold booting.... I can't be bothered
> looking to verify this fully but certainly a grep -r ldconfig
> /etc/rc.* returned nothing.
Yes, I assumed that given its functionality that it was run at boot
time. Given its functionality, if it is not run at boot time then
somebody has stuffed up, because this level of caching should be run at
boot time, unless there is something else run that does the same thing.
>
> If you start hacking about with things then it's much harder to give
> support. If you start hacking it's assumed you can poke about and fix
> things yourself.
I added the module paths into xorg.conf (reflecting what used to have to
be supplied) so that xorg would pick up the nvidia driver and gl driver
directly, rather than go through alternatives processing which cooker
does by default, when I was resolving the cooker performance issues on
my system with Stefane. Doing this significantly improved performance,
particularly with kicker menu caching (I don't have any figures to back
this up, it is general perception).
>
> And remember that the x11 module is only part of the whole GL
> solution. The shared library (and sometimes a kernel module) make up
> the other part(s).
This might be true but the
/usr/lib/xorg/modules/extensions/nvidia-current/libglx.so is a link to
/usr/lib/xorg/modules/extensions/nvidia-current/libglx.so.173.08 which I
assume is the module with the unknown symbol and hence can't be loaded.

regards,
Steve

>
> Col
>
>
>