Colin Guthrie wrote:
> Steve Morris wrote:
>> I have one more question before I let this rest. When the ldd is
>> issued against libglx.so is it really listing the dependencies, in
>> this case, of libglx.so.173.08, as I don't understand how a symlink
>> can have dependencies as it is only a pointer isn't it?
>
> For clarity, the symlink itself doesn't have the dependancies.
> Symlinks are filesystem level and applications/tools (like ldd) are
> (typically) unaware of their existence.
>
> When ldd is run on a symlink it's the equivalent to running ldd on the
> file the symlink points to.
>
> Which is the longer version of Anssi's "yes" ;)
>
> I'll try and summarise everything for you as there is still some
> confusion as to why this is so complex (I don't think it is all that
> complex but hey!). For clarity, this is all about libGL and
> applications that want to use it. The X11 glx module is just such an
> "application".
>
> There are several versions of the libGL library. The default one is
> the one shipped in Mesa which is /usr/lib/libGL.so.1 (provided by the
> libmesagl1 package).
> [colin@(protected)*
> lrwxrwxrwx 1 root root   12 2008-05-12 09:38 /usr/lib/libGL.so.1 ->
> libGL.so.1.2*
> -rwxr-xr-x 1 root root 427712 2008-05-09 20:38 /usr/lib/libGL.so.1.2*
>
> There are also others for nvidia-current, nvidia71xx, nvidia96xx and
> fglrx (ATI). These are stored in /usr/lib/nvidia-current/,
> /usr/lib/nvidia71xx/, /usr/lib/nvidia96xx/ and /usr/lib/fglrx/
> respectively.
>
> So with all these different versions we have to find a way to supply
> an application that wants to load the GL library with the correct one.
> If you have intel h/w you'll want the mesa one, if you have recent
> nvidia h/w and are using the prop. driver you'll want the
> nvidia-current one etc.
>
> In order to do this we configure the dynamic linker appropriately and
> this is where the gl_conf alternatives system comes in.
>
> By default we ship with the gl_conf alternative that is shipped in
> x11-server-common which is the file: /etc/ld.so.conf.d/GL/standard.conf.
> They dynamic linker does not look at any subfolders in the
> /etc/ld.so.conf.d/ folder, so this file (standard.conf) is completely
> useless by itself. It's only useful when it's symlinked to
> /etc/ld.so.conf.d/GL.conf. This is how my system is currently configured.
>
> When you want to use the nvidia-current libGL, it will symlink
> /etc/ld.so.conf.d/GL.conf to /etc/ld.so.conf.d/GL/nvidia-current.conf
> (not 100% sure of this name but the principle is correct). This
> changes the library search order and ensure that any application that
> wants to load libGL will load the nvidia-current one (provided the
> dynamic linker has an up-to-date cache; which is updated by ldconfig;
> which only needs to run when libraries are installed/removed or the
> search path order is changed (as happens when gl_conf is reconfigured).
>
>
> I hope this explanation is clear and that you now appreciate the need
> for this system. If there was only one version of the libGL.so.1
> library then this wouldn't be needed.
>
> Col
>
>
Thanks Col, I understood the symlinks and the update-alternatives
processing, what I didn't understand was why there was duplication of
modules between /usr/lib/nvidia-current and
/usr/lib/xorg/modules/extensions(/nvidia-current) but on closer
inspection, one directory has libgl modules whereas the other one has
libglx modules. This is where I was getting confused. I would agree that
/etc/ld.so.conf.d/GL/standard.conf is not much use considering it is empty.

On a separate note I will have to check things with update-alternatives
as it appeared to not work properly with java, but it has been some time
since I looked at that process so I will need to revisit it to verify
things properly.

regards,
Steve

>
>
>