Steve Morris wrote:
> Colin Guthrie wrote:
>> Steve Morris wrote:
>>> I have now run ldconfig (I have never had to run this in the past for
>>> dependent processes to pick up the update-alternatives changes, so I
>>> don't understand why I need to now),
>>
>> FYI it's not related to calling update-alternatives generally, but in
>> this case the alternative affects a file in /etc/ld.so.conf.d/ which
>> in turn affects the library search path. That's why ldconfig is needed
>> in this case.
> I don't understand why this is the case. With the module path entries I
> had in Xorg.conf Xorg was loading
> /usr/lib/xorg/modules/extensions/nvidia-current/libglx.so which is a
> link to libglx.so.173.08 in the same directory. Without these module
> paths Xorg's default functioniality is to load
> /usr/lib/xorg/modules/extensions/libglx.so with is a link to
> /etc/alternatives/libglx with is a link to
> /usr/lib/xorg/modules/extensions/nvidia-current/libglx.so which is a
> link to libglx.so.173.08 in the same directory. So how does
> /usr/lib/nvidia-current as specified by ldconfig get into the picture?

libglx.so depends on libGLcore.so.1 and libnvidia-tls.so.1, that are in
/usr/lib/nvidia-current:

$ ldd /usr/lib64/xorg/modules/extensions/nvidia-current/libglx.so
    linux-vdso.so.1 => (0x00007fffb03fe000)
    libGLcore.so.1 => /usr/lib64/nvidia-current/libGLcore.so.1
(0x00002b64faa41000)
    libnvidia-tls.so.1 =>
/usr/lib64/nvidia-current/tls/libnvidia-tls.so.1 (0x00002b64fb5f9000)
    libc.so.6 => /lib64/libc.so.6 (0x00002b64fb6fa000)
    /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)


> It was all this circular link chaining that caused me to put the
> modulepath statements in xorg.conf to go straight to the correct libglx
> module.
>

--
Anssi Hannula