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). Is there any reason why this module has
the runtime dependency rather that statically linking the modules in, or
does such a concept not exist in Linux?

regards,
Steve