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.

--
Anssi Hannula