Anssi Hannula wrote:
> Steve Morris wrote:
>  
>> Anssi Hannula wrote:
>>  
>>> Steve Morris wrote:
>>>
>>>    
>>>> Anssi Hannula wrote:
>>>>  
>>>>      
>>>>> 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.
>>>>>
>>>>>      
>>>>>      
>>>> So everytime a .so module calls a symbol does the loader search the
>>>> external symbol table of all modules on the library path to find the
>>>> library that exposes that symbol, or does it have some other means of
>>>> determining what is the correct library to load when asked?
>>>>  
>>>>      
>>> No, the .so contains a list of the libraries that need to be loaded:
>>>
>>> $ objdump -p /usr/lib64/xorg/modules/extensions/libglx.so | grep NEEDED
>>>  NEEDED          libGLcore.so.1
>>>  NEEDED          libnvidia-tls.so.1
>>>  NEEDED          libc.so.6
>>>
>>> If the loader cannot locate one of the libraries, or if all symbols are
>>> not resolved after the libraries are loaded, an error is generated.
>>>
>>>  
>>>    
>> OK, I understand now what is going on. I would have thought that it
>> would have been better to build a runtime dependency on say libGLcore.so
>> and let the symlink take care of what was the current version (but that
>> is just personal preference).
>>  
>
> If the major number (libfoo.so."1") changes, it means the new library is
> not fully backward-compatible. Therefore we do not want to load
> libfoo.so.2, if libfoo.so.1 is expected.
>
>  
>> Is there any reason why this module has
>> the runtime dependency rather that statically linking the modules in,
>>  
>
> Yes, the symbols libGLcore.so.1 contains are also used by libGL.so.1.
>
>  
>> or
>> does such a concept not exist in Linux?
>>  
>
> It does, but we usually want tot avoid it.
>
>  
Ok, I'll let things rest, I could continue on ad infinitum here, I guess
I will just have to accept that Mandriva/Linux does things in a way that
just makes no logical sense to me.

regards,
Steve