Shortly after attempting to start a skirmish game in Q3A, in fact almost anything, the X server dies and returns me to the command line. There is an error that reads something like "detected attempt to write across stack boundary". Doesn't happen if I use the libGL.so.1.2 from the XFree86 build tree. Bit of an impedance mismatch between the two?
Are you seeing the same problems in any other applications? I don't have Q3A to reproduce this (and we generally can't support proprietary software like Q3A, it's virtually impossible to debug).
No, but it doesn't happen with the version from the XFree86 build tree, so I'm considering this a side-effect of Red Hat's choice to maintain a separate Mesa package. You could use the libGL.so from XFree86 and just build libOSMesa from the standalone Mesa sources. As of last week libGLU is in the XFree86 tree as well, so the separate Mesa package is looking less useful all the time. By all means rip the GL stuff out of the X tree and package it separately :)
The package is definitely necessary and must be called libGL: The XFree86 libGL doesn't do software rendering (it works only on cards supported by DRI) and doesn't work with XFree86 3.3.6 (yes, there are still cards that work only with 3.3.x).
The one I'm using happily falls back to software rendering when I chmod /dev/dri/card0 to prevent access ... and plenty of people have problems actually enabling DRI when they have got the right library :) Seriously, this is a pain ... and it's only seasoned people who can read the docs and have the opportunity to rebuild stuff from source who fix it. Hack a version together that does work with 3.3.6 (is there any way to hack both Utah-GLX and DRI support in ?)
I'm toying with making the GL stuff from XFree86 into a separate XFree86-GL or -DRI package, which could be installed instead of Mesa for those who would benefit from it. Would you consider this an option ?
Yes....other people can benefit from this too, like myself. I use the NVIDIA GL drivers and everytime I update XFree I need to go and delete all the GL files from it since they conflict with nvidia's stuff.
Uh, no ... currently the GL stuff from XFree86 is NOT included in the Red Hat packages. I'm suggesting they DO include it, but split out into a separate package that can be installed instead of Mesa.
Well, how about the files /usr/X11R6/lib/modules/extensions/libglx.a and libGLcore.a or .so in the same directory? They are in the XFree86 rpms and according to Nvidia I am supposed to delete them (in addition to Mesa stuff of course).
That's nVidia's problem, not Red Hat's problem. nVidia chose to bypass the mechanisms built into XFree86-4.x and develop their own (direct?) rendering infrastructure, and so cannot cohabit with the XFree86 version. This also, presumably, makes it difficult to support both an nVidia chipset and any other card using the same server ... AFAIK, those files are not part of Mesa either. That said, it might well be a good idea to package those particular files together with the libGL library.
The problem is that we need software rendering even for cards not supported by XFree86 4.0.x at all (using XFree86 3.3.x servers), so using the XFree86 libGL is not an option ATM. This will be fixed in XFree86 4.2.0 though (they're adapting the patch).
OK, I finally got my head around this (in part by reading an exchange between Mike and the DRI-Devel mailing list :o) The most recent XFree86/Mesa combination I tried did actually work, although it wasn't completely stable; the instability is basically fixed now in the DRI & XFree86 CVS trees by a completely new version of the DRI/DRM. So this is no longer a problem, basically. My apologies to Mike and Bernard for the complaints.