PDA

View Full Version : OpenGL libraries linking problem



JMO
26th July 2008, 09:34 PM
This must have been asked a lot, but I really couldn't find answers to my problem.

I'm trying to run some Kenta Cho games and on each one of them this is the response:

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

Recently I installed Google Earth and the message is the same. I'm pretty sure to have installed the i386 libraries of mesa and other stuff required, but my guess is that the programs are looking on the wrong path. How can I change that?

Thanks a lot.

Seve
26th July 2008, 09:45 PM
Hello:
Try

yum install mesa-libGL-7.1-0.37.fc9.i386

This is the package which provides libGL.so.1 32bit

Seve

JMO
27th July 2008, 05:50 PM
I already have it =o

Hlingler
27th July 2008, 06:03 PM
Just a hunch: you running x86_64 (64-bit) OS? If so, you need to install the x86 (i386) flavor of the package in question also, to get the i386 version of that library. That would explain the PATH finding problem (looking in /usr/lib/ not found because it's 64-bit in /usr/lib64/). Also need to have 32-bit compatibility package installed if using proprietary driver.

If you are running x86 already and/or have the x86/i386 package installed for sure, then... not sure, maybe a problem with proprietary drivers? That's happened before. In that case, verify package integrity:
rpm -V mesa-libGL

and then start Google-Earth or whatever from command line with:
LD_LIBRARY_PATH="/usr/lib" LIBGL_DRIVERS_PATH="/usr/lib/dri" <program-name>

V

JMO
28th July 2008, 06:59 PM
I'm running a x86_64 system.
Look... this is what rpm -V mesa-libGL gives me

[root@localhost ~]# rpm -V mesa-libGL
....L... /usr/lib64/libGL.so.1
S.5....T /usr/lib64/libGL.so.1.2
missing /usr/lib/libGL.so.1
S.5....T /usr/lib/libGL.so.1.2

I checked it and both i386 and x86_64 are installed =o

Hlingler
28th July 2008, 08:07 PM
Well, there's the answer to your problem then:
I'm running a x86_64 system.
Look... this is what rpm -V mesa-libGL gives me

[root@localhost ~]# rpm -V mesa-libGL
....L... /usr/lib64/libGL.so.1
S.5....T /usr/lib64/libGL.so.1.2
missing /usr/lib/libGL.so.1
S.5....T /usr/lib/libGL.so.1.2

I checked it and both i386 and x86_64 are installed =oThe 32-bit libGL.so.1 library is in fact mysteriously... not there. The packages are installed, yes, but the output says that file is gone. "No such file or directory." Missing in action. AWOL.

Manually fetch and download the 32-bit mesa-libGL package and re-install it.

V

EDIT: Nevermind, you don't have to go through that trouble: the file /usr/lib/libGL.so.1 is just a symbolic link to the real library (but needs to exist). Just re-create it (as root user):
ln -s /usr/lib/libGL.so.1.2 /usr/lib/libGL.so.1

That first letter is lowercase "L" as in link

JMO
29th July 2008, 08:59 PM
It says now

error while loading shared libraries: /usr/lib/libGL.so.1: invalid ELF header

Should I download and put manually the file there?

Hlingler
30th July 2008, 04:02 AM
It says now

error while loading shared libraries: /usr/lib/libGL.so.1: invalid ELF header

Should I download and put manually the file there?Yes, at this point I would replace/re-install the 32-bit mesa-libGL package, as it seems damaged and has at least that one file missing. Find out the current version:
rpm -q mesa-libGL

Both 32-bit and 64-bit should be same version. Go fetch another copy of mesa-libGL (32-bit) correct version from rpm.pbone.net or rpmfind.net. Re-install with:
[sudo] rpm -Uvh --replacefiles --replacepkgs mesa-libGL*.i386.rpm

Good Luck,
V

JMO
30th July 2008, 09:43 PM
I'd downloaded the file mesa-libGL-7.1-0.37.fc9.i386.rpm, and tried to install it with the command you gave me, but weirdness grows:

[root@localhost Descargas]# rpm -Uvh --replacefiles --replacepkgs mesa-libGL-7.1-0.37.fc9.i386.rpm
Preparando... ########################################### [100%]
1:mesa-libGL ########################################### [100%]
/sbin/ldconfig: /usr/lib64/libGL.so.173.14.05 no es un fichero ELF - tiene los bytes mágicos equivocados en el comienzo.

/sbin/ldconfig: /usr/lib64/libGLcore.so.173.14.05 no es un fichero ELF - tiene los bytes mágicos equivocados en el comienzo.

/sbin/ldconfig: /usr/lib64/libGL.so.1.2 no es un fichero ELF - tiene los bytes mágicos equivocados en el comienzo.

/sbin/ldconfig: /usr/lib64/tls/libnvidia-tls.so.173.14.05 no es un fichero ELF - tiene los bytes mágicos equivocados en el comienzo.

Is something like "that is not an ELF file - has the wrong magic bytes at the beggining"

???

Hlingler
30th July 2008, 10:36 PM
Yes, I can read that....

First of all, the replacement of package mesa-libGL.i386 was successful. You can verify that again with:
rpm -V mesa-libGL

The message that follows is not directly related to the replacement of that package. It occurred during the execution of a post-install script in the RPM. However...

You appear to have two problems:
(1) You failed to mention that you have previously installed the proprietary NVidia driver using the "blob" binary from NVidia Corp. :( In addition, it's an outdated version. :eek: Current stable version is: 173.14.09.
(2) Using that "blob" has caused damage to your OS software. The binary installer has moved/replaced/overwritten certain critical files, as you have discovered. For that reason, use of the binary installer "blob" is not recommended.

To attempt to fix these problems, try the following:
> Re-run the binary installer with the 'uninstall' switch:
[sudo] sh NVIDIA-X.Y.Z.run --uninstall
> Verify that there is no further damage to the existing software:
rpm -V `rpm -qa|grep -i mesa`
rpm -V `rpm -qa|grep -i xorg`
rpm -V libdrm
Repair any damage as you did above with mesa-libGL.i386. If you are unsure as to what is acceptable/unacceptable, post back with the output of the query.
> Re-install the proprietary driver using the sanely packaged RPMs from Livna or some other 3rd-party repository. See the link in my signature.
> In future, please state clearly in advance all relevant details of your hardware and software configuration. :)

V

JMO
31st July 2008, 09:25 PM
I've tried to uninstall nVidia with the binary files, but I have the Livna package installed, not the official drivers package, so there are no results. On the other hand, here is the output of the commands you gave me

[root@localhost Descargas]# rpm -V `rpm -qa|grep -i xorg`
prelink: /usr/lib64/nvidia/tls/libnvidia-tls.so.173.14.09: section file offsets not monotonically increasing
S.?..... /usr/lib64/nvidia/tls/libnvidia-tls.so.173.14.09

[root@localhost Descargas]# rpm -V `rpm -qa|grep -i mesa`
....L... /usr/lib64/libGL.so.1
S.5....T /usr/lib64/libGL.so.1.2

[root@localhost Descargas]# rpm -V libdrm
.......T /etc/modprobe.d/i915modeset
.......T /etc/udev/rules.d/91-drm-modeset.rules

Hlingler
1st August 2008, 02:20 AM
Well, those files listed in your Post #9 came from somwhere, but not from the currently installed driver packages. The file locations are typical of the binary installer, not Livna's packages (compare files listed in Post #11).

In any case, those files need to be removed: they are obviously interfering with the other graphics libraries because the dynamic linker configurator is trying to bind them. In addition, it looks like the 64-bit mesa-libGL.so.1.2 library has been damaged or overwritten with an unusable file. You will need to find and remove them manually.

To do so, try the following (as root user):
rm `locate 173.14.05`

That command should locate all files with the "175.14.05" tag, and ask you if they should be erased. You will be asked to approve each file to be deleted - make sure that they are clearly spurious video driver files before you agree. I would expect there to be approximately 6-12 such files in total.

After that, re-install the 64-bit mesa-libGL package in the same way that you replaced the 32-bit one. Also verify that the current nvidia driver packages are not damaged:
rpm -V `rpm -qa|grep -i nvidia`

I would recommend a reboot of the PC after you finish all of the above steps.

The other results/output that you posted look perfectly normal.

Good Luck,
V