This section describes how to link your application with libGL.so and verify that you are in fact using 3D acceleration.
Your OpenGL program must link with the libGL.so.1.2 library provided by XFree86 4.0. The libGL.so.1.2 library contains a GLX protocol encoder for indirect/remote rendering and DRI code for accessing hardware drivers. In particular, be sure you're not using libGL.so from another source such as Mesa or the Utah GLX project.
Unless it was built in a special way, the libGL.so library does not contain any 3D hardware driver code. Instead, libGL.so dynamically loads the appropriate 3D driver during initialization.
Most simple OpenGL programs also use the GLUT and GLU libraries. A source for these libraries is listed in the Resources section below.
A simple GLUT/OpenGL program may be compiled and linked as follows:
gcc program.c -I/usr/local/include -L/usr/local/lib -L/usr/X11R6/lib -lglut -lGLU -lGL -o program
-I option is used to specify where the GL/glut.h (and
possibly the GL/gl.h and GL/glu.h) header file may be found.
-L options specify where the libglut.so and the X
libraries are located.
libGL.so and libGLU.so should be in /usr/lib, as specified by
the Linux/OpenGL ABI standard.
-lglut -lGLU -lGL arguments specify that the application
should link with the GLUT, GLU and GL libraries, in that order.
Simply typing ./program in your shell should execute the program.
If you get an error message such as
gears: error in loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directoryif means that the libGL.so.1 file is not the right location. Proceed to the trouble shooting section.
OSMesa (Off-Screen Mesa) is an interface and driver for rendering 3D images into a user-allocated block of memory rather than an on-screen window. It was originally developed for Mesa before Mesa became part of the XFree86/DRI project. It can now be used with the XFree86/DRI libGL.so as well.
libOSMesa.so implements the OSMesa interface and it must be linked with your application if you want to use the OSMesa functions. You must also link with libGL.so. For example:
gcc osdemo.c -lOSMesa -lGLU -lGL -o osdemo
In stand-alone Mesa this interface was compiled into the monolithic libGL.so (formerly libMesaGL.so) library. In XFree86 4.0.1 and later this interface is implemented in a separate library.
glxinfo is a useful program for checking which version of
libGL you're using as well as which DRI-based driver.
glxinfo and examine the OpenGL vendor, renderer,
and version lines.
Among the output you should see something like this:
OpenGL vendor string: VA Linux Systems, Inc. OpenGL renderer string: Mesa DRI Voodoo3 20000224 OpenGL version string: 1.2 Mesa 3.4
OpenGL vendor string: VA Linux Systems, Inc. OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.2 Mesa 3.4
The first example indicates that the 3dfx driver is using Voodoo3 hardware. The second example indicates that no hardware driver was found and indirect, unaccelerated rendering is being used.
If you see that indirect rendering is being used when direct rendering was expected, proceed to the troubleshooting section.
glxinfo also lists all of the GLX-enhanced visuals available
so you can determine which visuals are double-bufferd, have depth (Z)
buffers, stencil buffers, accumulation buffers, etc.
The libGL.so library recognizes three environment variables.
Normally, none of them need to be defined.
If you're using the csh or tcsh shells, type
setenv VARNAME value to set the variable.
Otherwise, if you're using sh or bash, type
LIBGL_DEBUG, if defined will cause libGL.so to print error
and diagnostic messages.
This can help to solve problems.
verbose may provide additional
LIBGL_ALWAYS_INDIRECT, if defined this will force libGL.so
to always use indirect rendering instead of hardware
This can be useful to isolate rendering errors.
LIBGL_DRIVERS_PATH can be used to override the default
directories which are searched for 3D drivers.
The value is one or more paths separated by colons.
In a typical XFree86 installation, the 3D drivers should be in
not be defined.
Note that this feature is disabled for set-uid programs.
This variable replaces the
LIBGL_DRIVERS_DIR env var used
in XFree86 4.0.
MESA_DEBUG, if defined, will cause Mesa-based 3D drivers
to print user error messages to stderr.
These are errors that you'd otherwise detect by calling
Mesa-based drivers (this includes most of the drivers listed
above) also observe many of the existing Mesa environment variables.
These include the