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.

--
Anssi Hannula