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

It only refreshes /etc/ld.so.cache that contains the library locations.

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

After changing gl_conf one needs to run ldconfig so that the correct
library gets listed first in /etc/ld.so.cache, so that the right openGL
library will be loaded.

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

Looks ok now. Could you try restarting X now and see if the unknown
symbol error still happens?

If it still happens, provide the output of
rpm -q x11-driver-video-nvidia-current
rpm -V x11-driver-video-nvidia-current

--
Anssi Hannula