Anssi Hannula wrote:
> 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.
>  
I thought ldconfig was caching all files in the listed directories and
hence would need to be run each boot.
The thing I don't understand is, in the past when the nvidia modules
have been knocked out, opengl based games like PlaneShift complain about
lack of hardware acceleration, running update-alternatives restored the
nvidia environment, which was enough to enable PlaneShift to run
properly, without running ldconfig. So why is ldconfig necessary after
running update-alternatives? I have never run ldconfig in the past after
update-alternatives gl_conf changes.
>  
>>> 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?
>
>  
ll provides the following output:

ll /usr/lib/xorg/modules/extensions/nvidia-current/libglx.so
lrwxrwxrwx 1 root root 16 2008-05-15 00:03
/usr/lib/xorg/modules/extensions/nvidia-current/libglx.so ->
libglx.so.173.08*

ldd provides the following output:

ldd /usr/lib/xorg/modules/extensions/nvidia-current/libglx.so
    linux-gate.so.1 => (0xffffe000)
    libGLcore.so.1 => /usr/lib/nvidia-current/libGLcore.so.1
(0xb7189000)
    libnvidia-tls.so.1 =>
/usr/lib/nvidia-current/tls/libnvidia-tls.so.1 (0xb7187000)
    libc.so.6 => /lib/i686/libc.so.6 (0xb7039000)
    /lib/ld-linux.so.2 (0x80000000)

regards,
Steve