On 12/26/09 03:51 PM, Paul Gress wrote:
directory and loads all modules that it finds. Maybe it scans
the mesa directory before the "GL" directory?
Maybe you can workaround the problem by hiding the
mesa subdirectory in /usr/lib/xorg/modules/extensions,
e.g. "tar cf mesa.tar mesa" and "rm -rf mesa" ?
I think the new Xorg is recursively scanning the extensions
I tried something similar and got mixed results.
I moved tne mesa directory to mesa.out and created a link for the new
mesa directory, the same as GL, so basically I had two directories the
same execpt for the name where one was GL and the other is mesa.
I rebooted, logged in went to the appearance settings to start compiz
and it started. I thought it was a hack, but at least I achieved
getting OpenGL working. Then I went to start an application that
required OpenGL, Pro-Engineer was the app. It wouldn't start and
complained about opengl with the wrong ELF. If your interested I
could recreated it and get the exact error message.
So, I'm now going to try what you suggest and see whatn happens.
_______________________________________________
OK, tried what you suggested. I could start compiz but with
Pro-Engineer, the same exact results as I previously got.
bash-4.0$ /Disk1/Binaries/Pro-Engineer/WF5/bin/proe1 &
[1] 2806
bash-4.0$ ld.so.1: pro: fatal: /usr/lib/libGL.so.1: wrong ELF class:
ELFCLASS32
Killed
[1]+ Exit 137 /Disk1/Binaries/Pro-Engineer/WF5/bin/proe1
bash-4.0$
Hopefully this can clue somebody what the real problem is. If I try to
analyze whats happening, my computing platform is running 64 bit and
libGL.so.1 is 32 bit, maybe there lies the problem.
I'm going to have to research more.
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
