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?
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.

regards,
Steve

>
> If I were to change the MTA via alternatives (not sure we still
> support this - we used to and it's just an example anyway!), I
> wouldn't need to run ldconfig.
>
>