Java Mailing List Archive

http://www.redhatconfig.com/

Home » Mandriva Cooker »

Re: [Cooker] Cooker update knocked out nvidia driver and nvidias
opengl driver

Colin Guthrie

2008-06-05

Replies: Find Java Web Hosting

Author LoginPost Reply
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





--

+--------------------------+
|    Colin Guthrie     |
+--------------------------+
| cguthrie(at)mandriva.org |
| http://colin.guthr.ie/ |
+--------------------------+
©2008 redhatconfig.com - Jax Systems, LLC, U.S.A.