To return expected results, you can:

Reduce the number of search terms. Each term you use focuses the search further.

Check your spelling. A single misspelled or incorrectly typed term can change your result.

Try substituting synonyms for your original terms. For example, instead of searching for "java classes", try "java training"

Did you search for an IBM acquired or sold product ? If so, follow the appropriate link below to find the content you need.

Problem

Attempts to run programs depending on the 64-bit libGL library may fail to execute due to a broken symbolic link referring to it. An error message such as the following could result, if an application is executed which depends on the reference: error while loading shared libraries: libGLU.so: cannot open shared object file: No such file or directory

Attempts to run programs depending on the 64-bit libGL library may fail to execute due to a broken symbolic link referring to it. An error message such as the following could result, if an application is executed which depends on the reference:

error while loading shared libraries: libGLU.so: cannot open shared object file: No such file or directory.

Affected configurations

The system may be any of the following IBM servers:

IBM System Cluster 1350, type 1410, any model

This tip is not software specific.

This tip is not option specific.

The system has the symptom described above.

Workaround

Re-install the NVIDIA Linux driver. For example:

libGL is one (1) of the libraries implementing application access to the functions in the OpenGL graphical framework.

libGL is made available to Red Hat and SUSE Enterprise Linux distributions in the following RPMs:

RHEL 6.4 x86_64: mesa-libGL-9.0-0.7.el6.x86_64 SLES 11.3 x86_64: Mesa-9.0.3-0.17.1

If the package in question is already installed, libGL will be present on the system in the /usr/lib64 directory:

/usr/lib64/libGL.so.1 -> libGL.so.1.2.0
/usr/lib64/libGL.so.1.2 -> libGL.so.1.2.0
/usr/lib64/libGL.so.1.2.0

The symbolic links redirect applications which refer to libGL to the correct library version. In the above example, references to either libGL.so.1 or libGL.so.1.2 will be redirected to libGL.so.1.2.0.

Installing the NVIDIA Video driver for Linux also installs its own version of libGL. Installing NVIDIA-Linux-x86_64-319.72.run in the same system would result in the following changes:

/usr/lib64/libGL.so -> libGL.so.1
/usr/lib64/libGL.so.1 -> libGL.so.319.72
/usr/lib64/libGL.so.319.72

At this point, references to libGL are redirected to libGL.so.319.72, which is correct.

Certain applications, such as the sample programs in the NVIDIA Cuda API Toolkit, also require amongst others the development versions of the Mesa RPMs:

RHEL 6.4 x86_64: mesa-libGL-devel-9.0-0.7.el6.x86_64 SLES 11.3 x86_64: Mesa-devel-9.0.3-0.17.1

(where API = application programming interface, RPM = Red Hat Package Manager)

The Mesa development RPMs also include libGL references, which will overwrite the libGL references as below:

/usr/lib64/libGL.so -> libGL.so.1.2.0
/usr/lib64/libGL.so.1 -> libGL.so.319.72
/usr/lib64/libGL.so.319.72

Note at this point that references to libGL.so now point to libGL.so.1.2.0, which no longer exists on the system. In this state, applications referring explicitly to libGL.so will generate an error on execution.

Reinstalling the NVIDIA Linux driver overwrites the broken reference and corrects the problem.

/usr/lib64/libGL.so -> libGL.so.1
/usr/lib64/libGL.so.1 -> libGL.so.319.72
/usr/lib64/libGL.so.319.72