Mantis - Croquet
Viewing Issue Advanced Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
385 Any feature always 10-14-04 12:07 10-17-04 12:28
Reporter: jredrejo Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
Summary: 0000385: The Croquet.sh scripts doesn't work in Debian with nvidia cards
Description: Using Debian with nvidia propietary drivers makes the Croquet.sh script fails. This scripts checks if /usr/lib/libGL.so is an executable file, but with nvidia drivers it is a symlink and avoid this script creating the necessary link to $EXE/libGL.so, making Croquet fails whenever you try to use any of the Teapot objects.
Steps To Reproduce:
Additional Information:
Relationships
Attached Files:

Notes
(0000384)
bert   
10-14-04 12:44   
What do you mean with "the script fails"? There *is* already a /usr/lib/libGL.so symlink? If yes, no link needs to be created in the bin directory.
(0000386)
jredrejo   
10-14-04 19:53   
Not exactly .
Before installing nvidia drivers, with X11 original drivers there is a symlink /usr/lib/libGL.so ->libGL.so.1.2
After installing nvidia drivers this is the new situation:
lrwxrwxrwx 1 root root 12 2004-09-02 13:54 /usr/lib/libGL.so -> libGL.so.1.2
lrwxrwxrwx 1 root root 17 2004-09-02 13:13 /usr/lib/libGL.so.1 -> libGL.so.1.0.6106
-rw-r--r-- 1 root root 420976 2004-07-01 07:26 /usr/lib/libGL.so.1.0.6106

The problem is that libGL.so.1.2 disappears, so the libGL.so symlink is broken. The Croquet.sh scripts detects that it exists and doesn't do the good work. Just
doing ln -sf /usr/lib/libGL.so.1 "$EXE/libGL.so" solves the problem, but it is not done by that script.

If you read the slashdot.com and barrapunto.com threads about croquet you will see that there are more debian & nvidia users complaining because Croquet doesn't work.
Regards
(0000393)
bert   
10-16-04 02:56   
Thanks for the clarification. So we should create the symlink regardless of whether there is one in /usr/lib. It's actually the system that's broken, but what the heck, we can do this easily.
(0000413)
ned   
10-16-04 22:30   
I think you need a new version of the nvidia package. On my system (with the 6111 version) everything works fine.

Have you tried running (as root)

ldconfig -v
(0000414)
bert   
10-16-04 22:50   
Ned, do you know for sure the newer nvidia installer will remove the stale libGL.so link?

Anyway, the safest way to prevent these kinds of misconfiguration would be to create a link to the library that B3DAcceleratorPlugin.so is actually linked to. A bit of ldd magic should solve this:

   ldd B3DAcceleratorPlugin.so | awk '/libGL.so.1/{print $3}'

OTOH, we *know* this is gonna be /usr/lib/libGL.so.1 on Linux, so why bother?
(0000423)
ned   
10-17-04 00:18   
In the changenote for nvidia-glx version 1.0.6106-3 it says:

Remove libglx.so.version symlink cleaning now that it is an actual file again.

What version are you using?
(0000426)
jredrejo   
10-17-04 12:28   
I am using version 6106, but I have solved the problem. In my computer now it works perfectly doing by hand the symlink ln -sf /usr/lib/libGL.so.1 "$EXE/libGL.so". The problem is for many people (in Spain, for example, http://barrapunto.com/article.pl?sid=04/10/12/217203&mode=thread [^] many people complain, and barrapunto is the spanish spoken slashdot.com) who are trying to use it. I know is a fail with nvidia drivers, but , if we can solve it so easily as doing that symlink anyway I think it should be done.