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.

> then it is smart enough to specify the error on that module not
> the original link. Even better would be for it to list the chain so that
> a determination could be made as to how it got there.


--
Anssi Hannula