Red Hat Bugzilla – Bug 24231
X server (4.0.2-1) dies shortly after starting Q3A skirmish
Last modified: 2007-04-18 12:30:45 EDT
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
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
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
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.