Colin Guthrie wrote:
>
> 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.
>

I understand your explanation, but it raises a question for me that may
be (some of) what is confusing Steve.

If all these versions of libGL are different, why don't the various
applications that want a specific version require them by specific name
? Then they could all be installed side-by-side, and the dynamic linker
could resolve them without the use of alternatives, no ?

I thought that the raison d'etre of alternatives was to allow a sysadmin
to seamlessly switch between different packages providing exactly the
same service with exactly the same API, e.g. postfix and sendmail. In
this case it looks like it's being used to allow mesa and the various
nvidia drivers to each blissfully assume that everybody else uses the
same version of the library they need.

Or is the point that everyone using libGL *has* to be using the same
version as the video driver ? In that case, alternatives makes more
sense. But I have two cooker systems, one with an nvidia card and one
without. Mesa is installed on both. On the nvidia system,
/etc/alternatives/gl_conf is symlinked to /etc/nvidia-current/ld.so.conf
and on the other it is symlinked to /etc/ld.so.conf.d/GL/standard.conf.
So how is mesa expected to work on both ?