Steve Morris wrote:
> 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.

It is run whenever you install/remove library packages, so there is no
need to run it on boot. You have to run it manually after using
update-alternatives to change gl_conf.

>> 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).

That must've been caused by something else, as the symlinks do not
affect performance after the file has been loaded.

>>
>> 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.

This sounds to me like a version mismatch of nvidia libraries.

What does
ldd /usr/lib/xorg/modules/extensions/nvidia-current/libglx.so
print?


--
Anssi Hannula