Java Mailing List Archive

http://www.redhatconfig.com/

Home » Mandriva Cooker »

Re: [Cooker] Cooker update knocked out nvidia driver and nvidias
opengl driver

Anssi Hannula

2008-06-04

Replies: Find Java Web Hosting

Author LoginPost Reply
Steve Morris wrote:
> Anssi Hannula wrote:
>> Steve Morris wrote:
>>
>>> Colin Guthrie wrote:
>>>  
>>>> Steve Morris wrote:
>>>>    
>>>>> Colin Guthrie wrote:
>>>>>    
>>>>>> 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.
>>>>>      
>>>> To assume makes an ASS of U and ME ;) It's probably not that library
>>>> that has the missing symbol but the library it's loading. e.g. it's
>>>> probably trying to load libGL.so.1 or something. It expects to load
>>>> the nv provided version of this library but it's actually loading the
>>>> nvidia one.... this could be due to outdated library paths in the
>>>> ld.so.conf.d folder (or more accurately, the paths are probably fine
>>>> after having been set corretly by update_alternatives gl_conf but an
>>>> outdated cache due to not running ldconfig is causing the wrong
>>>> library to be loaded...).
>>>>    
>>> I certainly hope this is not the situation as that makes a mockery of
>>> the error message. Using your example of libGL.so.1, if xorg is smart
>>> enough to determine that it is this module that has the undefined
>>> symbol,
>>>  
>>
>> It is not. And the error is actually from dynamic linker (dl.so), that
>> cannot load libglx.so as there are undefined symbols. And it cannot know
>> where the symbols were supposed to be defined, only that they are not
>> defined.
>>  
> Is it the situation that xorg issued an explicit call to the undefined
> symbol, and is it the case that if so it is relying on module chaining
> the get to the module containing the symbol it wants rather than calling
> the module directly as it should.

No. In libglx.so there are calls to symbols that are not defined on any
of it library dependencies. The dynamic loader resolves all symbols when
libglx.so is loaded, and fails if libglx.so contains calls to
nonexistent symbols.

--
Anssi Hannula
©2008 redhatconfig.com - Jax Systems, LLC, U.S.A.