Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 19776 - OpenGL segfault in libGL.so.1.2
Summary: OpenGL segfault in libGL.so.1.2
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: Sparc Linux
: High normal (vote)
Assignee: Ferris McCormick (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-04-22 10:22 UTC by Ferris McCormick (RETIRED)
Modified: 2006-02-04 06:05 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Current complete XF86Config file. (XF86Config,4.26 KB, application/octet-stream)
2003-04-22 10:27 UTC, Ferris McCormick (RETIRED)
Details
Current complete XF86Config file. (XF86Config,4.26 KB, text/plain)
2003-04-22 10:28 UTC, Ferris McCormick (RETIRED)
Details
stripped down sparc.c (sparc.c,2.87 KB, text/plain)
2003-04-25 08:28 UTC, Ferris McCormick (RETIRED)
Details
patch based on suggestions from Azarah (sparc64.patch,155.50 KB, patch)
2003-10-02 17:00 UTC, Jason Wever (RETIRED)
Details | Diff
Patch in GLapi dispatch table initialization for xfree-libGL (glx.patch,3.47 KB, patch)
2003-12-04 10:31 UTC, Ferris McCormick (RETIRED)
Details | Diff
Corresponding patch for xc/lib/GL/glx/glxext.c, zfree-4.3.0-r3 (glx.patch,3.46 KB, patch)
2003-12-06 08:20 UTC, Ferris McCormick (RETIRED)
Details | Diff
Automate the #ifdef --> #if (defined(_sparc_v9__).... changes to xc/extras/Mesa (PATCH_V9,1.28 KB, text/plain)
2003-12-09 08:47 UTC, Ferris McCormick (RETIRED)
Details
Patch to today's cvs ebuilds for -r5, -r6 which fixes this bug. (19776.patch,4.68 KB, patch)
2004-04-19 12:31 UTC, Ferris McCormick (RETIRED)
Details | Diff
The patch file referenced ain the previous attachment as ${FILESDIR}/sparc-glx-4.3.0-patch (sparc-glx-4.3.0.patch,3.46 KB, patch)
2004-04-19 12:37 UTC, Ferris McCormick (RETIRED)
Details | Diff
Entire fix for sparc, xfree-4.3.0, as one big patch file (19776.patch,197.76 KB, patch)
2004-04-20 05:12 UTC, Ferris McCormick (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ferris McCormick (RETIRED) gentoo-dev 2003-04-22 10:22:25 UTC
As in summary, on an Ultra2/Creator3D (FFB2+(H)) system
CFLAGS="-mcpu=v8 -mtune=v9 -O2 -pipe"
after 
ebuild xfree-4.3.0-r2.ebuild fetch unpack compile install qmerge
etc-update
xinit
glxgears

I get Segfault in 
/usr/lib/opengl/xfree/lib/libGL.so.1.2*


Reproducible: Always
Steps to Reproduce:
1.install xfree-4.3.0-r2
2.etc-update (all 80 of them)
3.glxgears

Actual Results:  
Segfault

Expected Results:  
most anything else; best would be some spinning gears.

All openGL applications demonstrate the same failure.  'uname -srvmpio' shows:

Linux 2.4.20-sparc-r0 #3 SMP Fri Jan 3 15:56:09 UTC 2003 sparc64 sun4u TI
UltraSparc II  (BlackBird) GNU/Linux
-----------------------------------------
The Module section in XF8sConfig shows:

Section "Module"
  Load  "dbe"
  Load  "type1"
  Load  "speedo"
  Load  "drm"
  Load  "dri"
  Load  "glx"
  Load  "extmod"
  Load  "freetype"
 # Load  "pex5"
 # Load  "record"
 # Load  "xie"
EndSection

and

Section "DRI"
 Group          "video"
 Mode           0666
EndSection
=======================================
And, here is the requested 'emerge info'
=======================================
lacewing X11 # emerge info
Portage 2.0.47-r10 (default-sparc64-1.4, gcc-3.2.2, glibc-2.2.5-r2,2.3.1-r4)
=================================================================
System uname: 2.4.20-sparc-r0 sparc64 sun4u
GENTOO_MIRRORS="http://gentoo.oregonstate.edu/
http://www.ibiblio.org/pub/Linux/distributions/gentoo"
CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config
/usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config
/usr/share/config"
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d"
PORTDIR="/usr/portage"
DISTDIR="/usr/portage/distfiles"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR_OVERLAY="/home1/portage"
USE="sparc apm avi cups encode fbcon gif jpeg mikmod mpeg ncurses nls png pdflib
spell truetype xv xml2 xmms gdbm berkdb slang readline tetex tcltk java guile X
sdl gpm tcpd pam libwww ssl perl python imlib gnome gtk qt kde motif opengl
mozilla cdr mysql -oggvorbis crypt -arts -alsa -esd -oss ruby tiff zlib"
COMPILER="gcc3"
CHOST="sparc-unknown-linux-gnu"
CFLAGS="-mcpu=v8 -mtune=v9 -O2 -pipe"
CXXFLAGS="-mcpu=v8 -mtune=v9 -O2 -pipe -Wno-deprecated -fpermissive"
ACCEPT_KEYWORDS="sparc"
MAKEOPTS="-j2"
AUTOCLEAN="yes"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
FEATURES="sandbox ccache"
==================================                  
I have marked the Severity as "Major" because if this is a bug anyplace but
on my system, it is severe.  (If it is something peculiar to my system, I'd
like to know that, too of course.)
Comment 1 Ferris McCormick (RETIRED) gentoo-dev 2003-04-22 10:27:35 UTC
Created attachment 10999 [details]
Current complete XF86Config file.

((Just for completeness))
Comment 2 Ferris McCormick (RETIRED) gentoo-dev 2003-04-22 10:28:15 UTC
Created attachment 11000 [details]
Current complete XF86Config file.

((Just for completeness))
Comment 3 Ferris McCormick (RETIRED) gentoo-dev 2003-04-23 07:06:08 UTC
And, if I just use .../libGL.so.1.2 from xfree-4.2.1-r2, "everything" (well,
glxgears & blender at least) work fine.  Better, if fact, than with
xfree-4.2.1.

So, even though the version number did not change, for me, sparc/openGL-4.3.0
is broken, and its size is significantly bigger.  I'll see if I can find out
anything more later.
-----------------------
lacewing lib # size *-r2
   text    data     bss     dec     hex filename
 362111   14841   12280  389232   5f070 libGL.so.1.2-4.2.1-r2
lacewing lib # size *-4.3.0
   text    data     bss     dec     hex filename
 417056   34080   12264  463400   71228 libGL.so.1.2-4.3.0
-----------------------
Comment 4 Ferris McCormick (RETIRED) gentoo-dev 2003-04-23 12:30:35 UTC
Third comment.  As best as I can tell from -gdb-, the abort comes from
glViewport, which is a tiny piece of sparc assembler code in glapi_sparc.S (in
/var/tmp/portage/xfree-4.3.0-r2/work/xc/extras/Mesa/src/SPARC which is linked to
/var/tmp/portage/xfree-4.3.0-r2/work/xc/lib/GL/glx/glapi_sparc.S); the failure
is independent of whether or not the __sparc_v9_ assembler version is used. (I
have tried both:  default is without, but you can get either version by playing
with the Makefile in .../glx.)  For reference, the code in its entirity reads:
-------------------
.globl glViewport
.type glViewport,#function
glViewport:     
#ifdef __sparc_v9__
        sethi   %hi(0x00000000), %g2
        sethi   %hi(0x00000000), %g1
        or      %g2, %lo(0x00000000), %g2
        or      %g1, %lo(0x00000000), %g1
        sllx    %g2, 32, %g2
        ldx     [%g1 + %g2], %g1
        sethi   %hi(8 * _gloffset_Viewport), %g2
        or      %g2, %lo(8 * _gloffset_Viewport), %g2
        ldx     [%g1 + %g2], %g3
#else 
        sethi   %hi(0x00000000), %g1
        ld      [%g1 + %lo(0x00000000)], %g1
        ld      [%g1 + (4 * _gloffset_Viewport)], %g3
#endif
        jmpl    %g3, %g0
        nop     

------------------
You get to this code indirectly, it appears, through a vector set up in
g_render.c.  The assembler code itself is generated by a script from a
template, but I haven't found them yet, as they do not seem to be part of the
xfree86 source.
Comment 5 Ferris McCormick (RETIRED) gentoo-dev 2003-04-24 10:19:45 UTC
More information:  Short description-- If you build in
/var/tmp/portage/xfree-4.3.0-r2/work/xc/lib/GL/glx
with "make ASM_DEFS=-UUSE_SPARC_ASM", after having edited 'glapi_sparc.S' with
appropriate "#ifdef USE_SPARC_ASM / #endif" (I put them around ".globl glNewList"
and right in fromt of ".globl _mesa_sparc_glapi_end" at the end of the routine),
then -glxgears- works fine.

So, on my system at least, the assembler code is wrong.

Unfortunately, there are several possible culprits; I am in free association mode now, so please be patient about my ramblings.

1.  For sake of argument, I believe that the code as presented works for
    XF86 testing, and possibly on every system but mine.
2.  I suspect but do not know that XF/Sparc testing is mostly Solaris based
    using Solaris compiler (because the Makefile as presented in ".../glx"
    cannot build a v9-specific version, but the assembler code certainly
    makes the distinction.  To get a v9 version with gcc, you have to make
    sure to "-D__sparc_v9__" and to set "-mv9" at every opportunity.)
3.  The assembler code makes lots of linkage/register assumptions.  As best
    as I can tell from gdb, the failing instruction (non-v9 mode) is
       ld [%g1],%g1
    or, in V9-mode,
       ldx [%g1 + %g2], %g3
    which says that the linkage assumptions are wrong (%g1 is not a good
    address.)  Here is what gdb says happens:
     %g1 = 0x800000 (entry -- certainly not a good data address)
     %g1 = 0        (not surprising after the sethi)
     Segfault       (not surprising after ld[%g1],%g1)
3a.  How can this possibly work? As I read the Sparc architecture, here's what
     the sequence does:
       sethi %hi(0),%g1
          %g1(bits 0-10) <- 0
          %g1(bits 32-63) <- 0
          %g1(bits 10-31) <- %hi(0) == 0
     I.e., %g1<-0
       ld [%g1],%g1  Load into %g1 indirect through %g1 (==0)
     Similarly, it looks to me like the -V9 version carefully sets %g1, %g2
     to 0 and then tries ldx [%g1+g2],....
4.  Unfortunately, at this point, I haven't determined if this is coming from
    a bad assumption on X's part, a gcc/X mismatch, a Linux(sparc)/X mismatch,
    or what.
More to come, I am sure.

Comment 6 Ferris McCormick (RETIRED) gentoo-dev 2003-04-24 13:43:02 UTC
OK, those "sethi %hi(0),..." instructions are supposed to be filled in at
library init to point to the real parameter list.  They are not.  (Someone is
supposed to walk through the entire pointer-to-glXXX blocks and do something like
  B[0] |= (glapi_addr >> 10);
  B[1] |= (glapi_addr & 0x3FF);
for non-V9, and something similar for V9, as in glapi.c+1870, but I haven't
found anything like that.)


Incidently, in the static version of the library, symbols like glViewport are
not defined at all (although with XF4.2 they were).

I would like to use the sparc assembler code, but it is beyond me at this point
to see how you are supposed to make it work.
Comment 7 Ferris McCormick (RETIRED) gentoo-dev 2003-04-25 08:28:28 UTC
Created attachment 11126 [details]
stripped down sparc.c
Comment 8 Ferris McCormick (RETIRED) gentoo-dev 2003-04-25 08:57:30 UTC
Here's how you fix it by hand.  I do not believe the code as provided & built is
complete.  We are in the directory <xc/lib/GL/glx> in the xfree-4.3.0-r2
build tree, with xfree-4.3.2-r2 already compiled and installed so that you are
using it.

1.  Remove the soft links for 'glapi.c', 'glapi_sparc.S', and copy the files in
    from <../../../../xc/extras/Mesa/src/[SPARC]>.  Bring in 'sparc.c' as well
    for reference (you are going to replace it in step 4).

2.  Edit glapi_sparc.S to include near the beginning the lines
  #ifdef __sparc_v9__
  #undef __sparc_v9__
  #endif
    because we never have 64-bit addresses around, whatever the compiler
    options.

3.  Apply this little patch to your private 'glapi.c'
=============================
--- glapi.c.orig        2003-04-25 13:00:01.000000000 +0000
+++ glapi.c     2003-04-25 13:00:24.000000000 +0000
@@ -51,6 +51,7 @@
 #include "glapitable.h"
 #include "glthread.h"
 
+extern void _glx_mesa_init_sparc_glapi_relocs(void); 
 /***** BEGIN NO-OP DISPATCH *****/
 
 static GLboolean WarnFlag = GL_FALSE;
@@ -305,6 +306,7 @@
       _glapi_Dispatch = dispatch;
    }
 #endif /*THREADS*/
+ _glx_mesa_init_sparc_glapi_relocs();
 }
================================

4.  Use the attached sparc.c for _glx_mesa_init_sparc_glapi_relocs() (or
    just add it to glapi.c -- we're talking about 12 lines of code here). This
    replaces the one you copied in at the beginning.

5.  If you kept the code separate, add sparc.o to the GLX_OBJS in the Makefile.

6.  make; cd ..; make; cp GL/libGL.so.1.2 /usr/lib/opengl/xfree/lib

With these changes, -glxgears- (and blender) work again.  Whether or not the
changes are any good in general, I cannot say.  Opengl as built out of the box
for sparc cannot possibly work, though, so far as I can make out.  (Or, if it does, what am I missing here?)
Comment 9 Alexander Jenisch 2003-05-04 09:53:47 UTC
german keyboard layout won't work correctly with r2. i can't type any characters that need "ALTGr" to be invoked, like "@, |, ?, \".

these are my localization settings:

LANG="en_GB"
LANGUAGE="en_GB" 
LC_CTYPE="de_DE@euro"
LC_NUMERIC="de_DE@euro"
LC_TIME="C" 
LC_COLLATE="de_DE@euro"
LC_MONETARY="de_DE@euro"
LC_MESSAGES="en_GB"
Comment 10 Alexander Jenisch 2003-05-04 09:55:22 UTC
sorry, ignore my last post. my browser mixed something up. this goes into "keyboard broken".
Comment 11 Joe Kallar (RETIRED) gentoo-dev 2003-06-23 07:52:59 UTC
Are you still having this issue or did you resolve it?
Comment 12 Ferris McCormick (RETIRED) gentoo-dev 2003-06-23 08:23:53 UTC
If you are asking about the keyboard question, ignore the rest of this comment;
I don't know anything about it.

If you are asking about the Segfault in /usr/lib/opengl/xfree/lib/libGL.so.1.2:

The changes outlined in comment 8 fix the problem for me.  Two other people have
reported the same problem (with xfree-4.3.0-r2, glxinfo & friends all segfault)
so I believe the problem is a genuine problem with xfree-4.3.0 as distributed.
(One reported the problem as a discussion in the sparc forum; one asked me directly.)  In one case, at least, the approach outlined above did correct the
problem.

As I read the code in the <.../lib/GL/glx> portion of libGL, the SPARC version
as distributed and configured by its .ebuild file cannot possibly work.

So, for me myself the problem is temporarily resolved (I know how to get
around it), but so far as I can see, the sparc/openGL portion of xf-4.3.0-r2
is broken.  <.../GL/glx> directory apparently doesn't get set up quite right
to handle the SPARC assembler code, but I have now idea how the problem was
indroduced (in xfree-4.2.xx, the problem is absent because glx doesn't try to
use any sparc-specific assembler.)

Hope this helps,
Regards
Comment 13 Carl Bach 2003-07-08 03:57:22 UTC
I just would like to conform the bug on my system. Xfree 4.3.0-r2, Elite3D (with the afb.ucode patch), glxgears *always* segfaults.
Comment 14 Martin Schlemmer (RETIRED) gentoo-dev 2003-08-26 12:54:10 UTC
Anybody tried -r3 yet ?  If not, I should be able to make that fix into a
sane patch, but I do not know when I will get to it though :(
Comment 15 Ferris McCormick (RETIRED) gentoo-dev 2003-08-26 13:21:24 UTC
I am running the fetch/unpack/compile part of -r3 as an ebuild; I will be able
to tell from the result in the lib/GL/glx directory whether or not the bug is
fixed.  I haven't tried to turn the bandaid fix into a good patch because:

1.  I don't know how, since the symbolic links is GL/glx are set up as part of
    the actual compile process in "make World"
2.  I don't know for sure if it puts the patch-all-the-addresses call in
    at the right place(s) in glapi.c

Regards,
Comment 16 Chris Russell (RETIRED) gentoo-dev 2003-08-27 04:40:10 UTC
Martin, I'm running -r3 but I have the "ATI Mach64 GT (264GT), aka 3D RAGE" and this bug may not apply... see output below

so when I run glxgears it goes like this:
Xlib:  extension "XFree86-DRI" missing on display ":0.0".
Segmentation fault
Comment 17 Ferris McCormick (RETIRED) gentoo-dev 2003-08-27 04:56:52 UTC
The source from '-r2' -> '-r3' did not change for xc/lib/GL/glx, so any fix 
would have been by some other means.  And, hand-executing 'glxinfo' suggests the
segfault bug is still present, thus:

antaresia lib # ./GL
#!/bin/bash -v
export LD_PRELOAD="/var/tmp/portage/xfree-4.3.0-r3/image/usr/lib/libGLU.so.1 /var/tmp/portage/xfree-4.3.0-r3/image/usr/lib/opengl/xfree/lib/libGL.so.1"
export LD_LOAD_PATH="/var/tmp/portage/xfree-4.3.0-r3/image/usr/lib:/var/tmp/portage/xfree-4.3.0-r3/image/usr/lib/opengl/xfree/lib" 
glxinfo
name of display: lacewing.inforead.com:0.0
Xlib:  extension "XFree86-DRI" missing on display ":0.0".
./GL: line 4: 21044 Segmentation fault      glxinfo
#

It occurs to me that the easiest fix might be to disable 
 ASM_DEFS = -DUSE_SPARC_ASM
*For lib/GL/glx only!*
until a good way to fix up the assembly version of the address patching
can be worked out.  In effect, this reverts libGL to how it was in 4.2.xx.
Note, though, I have not tried this, and I have no idea if it would work or
if the result would be compatible with everything else.

Note for Chris Russell:  The bug is xfree-4.3.x--on--sparc64 specific.  It
does not matter what your graphics card is, because libGL.so as built for
sparc64 in xfree-4.3.x is 100% broken.

Regards,
Ferris
Comment 18 Donnie Berkholz (RETIRED) gentoo-dev 2003-08-27 09:32:00 UTC
Chris, DRI for mach64 chipsets isn't in the portage tree yet. It'll hopefully show up with xfree-drm-4.3.0-r7, or when I can make it work. Until then, either check out http://www.retinalburn.net/linux/dri_HOWTO.html or comment out the dri module in /etc/X11/XF86Config like this:
# Load "dri"

Please follow bug #27099 instead of adding to this bug.
Comment 19 Martin Schlemmer (RETIRED) gentoo-dev 2003-09-01 11:22:29 UTC
Stupid question - what is the compile flags for xc/lib/GL/glx ?  It should
in theory have a '-m32' there if you have 32bit userland on sparc64 - is this
the case?  Or am I trying to find a problem where there is none ?
Comment 20 Jason Wever (RETIRED) gentoo-dev 2003-09-01 13:24:56 UTC
We are using 32-bit userland on sparc64.
Comment 21 Ferris McCormick (RETIRED) gentoo-dev 2003-09-01 15:46:46 UTC
So far as I know, there is no '-m32' flag, because it is always 32 bit for
users.  There is a problem, but it is not related to that, except for forcing
the assembler code always to run in 32-bit mode (that's the 
#ifdef __sparc_v9__
#undef __sparc_v9__
bit added to glapi_sparc.S).  It looks like the assembler stuff originally was done
on Solaris with the sun compiler, where 32 vs. 64 makes a difference.  Also,
under Solaris, the addresses in the assembler code must somehow get filled in
by Sun's driver some other way.  The problem here is that all those zeros in
the address fields on glapi_sparc.S need to be filled in at run time, and as distributed for Linux on Sparc, glx has no provision for doing so.

The code is fine and compiles fine; it's just incomplete under Linux.

Hope this helps.
Comment 22 Martin Schlemmer (RETIRED) gentoo-dev 2003-09-07 07:20:25 UTC
If I understand gcc correctly, it *should* only define __sparc_v9__ or __arc64__
if you have 'mcpu=v9'.  What happens if you change the '-mtune=v9' to '-mtune=v8'
?  Might be deeper than just xfree ...

Alternatively could you try attached patch:

-------------------------------------
--- xc/config/cf/Imake.cf.orig  2003-09-07 15:58:53.957841248 +0200
+++ xc/config/cf/Imake.cf       2003-09-07 16:23:13.302987064 +0200
@@ -1006,8 +1006,17 @@
 #endif /* QNX/Neutrino */
  
 #ifdef SparcArchitecture
-# if defined(__sparc_v9) || defined(__arch64__)
-#  define Sparc64Architecture
+# if defined(__sparc_v9__)
+#  undef __sparc_v9__
+# endif
+# if defined(__sparc_v9)
+#  undef __sparc_v9
+# endif
+# if defined(__arch64__)
+#  undef __arch64__
+# endif
+# if defined(Sparc64Architecture)
+#  undef Sparc64Architecture
 # endif
 #endif
  
Comment 23 Ferris McCormick (RETIRED) gentoo-dev 2003-09-07 10:03:29 UTC
1.  The bug is sparc/any dependent, not just sparc64.  E.g., you see it on SS20,
    SS5, etc (sun4m) as well as on sun4u. See #7 below. 

2.  The only reason __sparc_v9_ is a problem with libGL is that xfree assumes
   (it seems) a SUN/SOLARIS compiler, where __sparc_v9_ implies 64-bit code,
    and the assembly code in GLX assumes that.

3.  With Linux and the gcc compiler, __sparc_v9_ does not mean 64-bit code;
    there is no 64-bit user code on sparc/linux right now.

4.  The only point of the extra check in the assembler code is to make sure the
    64-bit linkages don't get set up (althought they might work, I suppose).

5.  If you are concerned primarily with sparc32 vs. sparc64 useland issues,
     the better fix looks something like
#if defined(__sparc_v9__) && (!defined(__linux__) || defined(__linux_sparc_64__))
...   <<where I made that last one up, because when linux has 64-bit sparc,
then the Solaris & gcc compilers are in sync>>

6.  So, there are two problems here.  First is the problem you are addressing,
    which is that there might be 64-bit code lurking in xfree, and indeed in
    any application which assumes a Sun compiler if you are on any sort of
    sparc.

    Second is the segfault problem, which is sun-cpu independent (it is sparc
    specific, but it is an equal opportunity failure, once you are sparc linux
    of any flavor.)

7.  By the way, in the original report, with
     CFLAGS="-mcpu=v8 -mtune=v9", this was saying:
    "compile for sun4m = Sparc32, but where it matters, do instruction
    scheduling to favor sun4u". You can easily prove this to yourself with
    'gcc -v -mcpu=v8 -mtune=v9' and notice that what gets defined is
     __sparc_v8__ which is strictly 32-bit.

    So when originally reported, this bug did not have any 64-bit-ness issues.

     The reason fur turning off __sparc_v9__ in the assembler code was to
    prevent any from creeping in.

    The "-mcpu=v8 -mtune=v9" idiom was for a version of gcc which sometimes
    "got it wrong" with cpu=v9, but the ebuilds seem to catch those cases, now.

8.  So now, I just '-mcpu=v9'.  But I didn't when I first reported this bug.
    And all the _v9__ stuff was "belt & suspenders" type paranoia.

    (I wish I'd left it out... it's something of a red herring... but to be
     completely safe, you do have to #undefine it in glapi.S...)

Does this help?  As I look it over, what I wrote confuses me.
Comment 24 Martin Schlemmer (RETIRED) gentoo-dev 2003-09-07 13:08:50 UTC
>1. The bug is sparc/any dependent, not just sparc64.  E.g., you see it on SS20,
>     SS5, etc (sun4m) as well as on sun4u. See #7 below. 
> 
> 2.  The only reason __sparc_v9_ is a problem with libGL is that xfree assumes
>    (it seems) a SUN/SOLARIS compiler, where __sparc_v9_ implies 64-bit code,
>     and the assembly code in GLX assumes that.
> 
> 3.  With Linux and the gcc compiler, __sparc_v9_ does not mean 64-bit code;
>     there is no 64-bit user code on sparc/linux right now.
> 

Yes, this I do understand.  XFree86 do not set __sparc_v9__ though,
so it is kernel/glibc/gcc side (difficult to check on non sparc system).

What I tried thus to say, is that if __sparc_v9__ also mean 64bit, then
linux/gcc/glibc sets it wrong, and it is a bug that should be fixed.  If
__sparc_v9__ do *NOT* indicate 64bit, then we have to fix xfree (for
linux at least)

>4. The only point of the extra check in the assembler code is to make sure the
>     64-bit linkages don't get set up (althought they might work, I suppose).
> 

Yep, that I do understand.  The issue is still if __sparc_v9__ donate
64bit, or if you should check __arch64__ to see if we need to generate
64bit code (yes, for linux obviously not).

>5.  If you are concerned primarily with sparc32 vs. sparc64 useland issues,
>      the better fix looks something like
> #if defined(__sparc_v9__) && (!defined(__linux__) || defined(__linux_sparc_64__))
> ...   <<where I made that last one up, because when linux has 64-bit sparc,
> then the Solaris & gcc compilers are in sync>>
> 

Right, but once again, does __sparc_v9__ indicate 64bit?  We might
change that patch like so:

--------------------------------------------
--- xc/config/cf/Imake.cf.orig  2003-09-07 15:58:53.000000000 +0200
+++ xc/config/cf/Imake.cf       2003-09-07 21:56:14.876326192 +0200
@@ -1006,8 +1006,14 @@
 #endif /* QNX/Neutrino */
  
 #ifdef SparcArchitecture
-# if defined(__sparc_v9) || defined(__arch64__)
-#  define Sparc64Architecture
+# if defined(__sparc_v9) || defined(__sparc_v9__) || defined(__arch64__)
+#  if defined(linux)
+#   if defined(__arch64__)
+#    undef __arch64__
+#   endif
+#  else
+#   define Sparc64Architecture
+#  endif
 # endif
 #endif
  
-------------------------------------------

And then apply to glapi_sparc.S:

-------------------------------------------
--- ../../../extras/Mesa/src/SPARC/glapi_sparc.S.orig   2003-09-07 21:58:38.171542008 +0200
+++ ../../../extras/Mesa/src/SPARC/glapi_sparc.S        2003-09-07 21:59:32.586269712 +0200
@@ -27,7 +27,7 @@
 .globl glNewList
 .type glNewList,#function
 glNewList:
-#ifdef __sparc_v9__
+#ifdef Sparc64Architecture
        sethi   %hi(0x00000000), %g2
        sethi   %hi(0x00000000), %g1
        or      %g2, %lo(0x00000000), %g2
@@ -48,7 +48,7 @@
.... etc for the rest
-------------------------------------------

And for any other piece that assume __sparc_v9__ imply __arch64__
(if __sparc_v9__ does indeed not imply __arch64__).

>6. So, there are two problems here.  First is the problem you are addressing,
>     which is that there might be 64-bit code lurking in xfree, and indeed in
>     any application which assumes a Sun compiler if you are on any sort of
>     sparc.
> 
>     Second is the segfault problem, which is sun-cpu independent (it is sparc
>     specific, but it is an equal opportunity failure, once you are sparc linux
>     of any flavor.)
> 
 
Right, and fixing the wrong assumption that __sparc_v9__ imply
__arch64__ for linux, this should be fixed as well ?

>7.  By the way, in the original report, with
>      CFLAGS="-mcpu=v8 -mtune=v9", this was saying:
>     "compile for sun4m = Sparc32, but where it matters, do instruction
>     scheduling to favor sun4u". You can easily prove this to yourself with
>     'gcc -v -mcpu=v8 -mtune=v9' and notice that what gets defined is
>      __sparc_v8__ which is strictly 32-bit.
> 
>     So when originally reported, this bug did not have any 64-bit-ness issues.
> 
>      The reason fur turning off __sparc_v9__ in the assembler code was to
>     prevent any from creeping in.
> 
>     The "-mcpu=v8 -mtune=v9" idiom was for a version of gcc which sometimes
>     "got it wrong" with cpu=v9, but the ebuilds seem to catch those cases, now.
> 
> 8.  So now, I just '-mcpu=v9'.  But I didn't when I first reported this bug.
>     And all the _v9__ stuff was "belt & suspenders" type paranoia.
> 
>     (I wish I'd left it out... it's something of a red herring... but to be
>      completely safe, you do have to #undefine it in glapi.S...)
> 

Yes, this I do understand.  gcc sources though want to indicate that
__sparc_v9__ is only set if you have -mcpu=v9, and *not* when -mtune is
set ... What does then set __sparc_v9__ ?  A gcc bug maybe ?  Is it
correct taht __sparc_v9__ should be set with -mcpu=v8, and -mtune=v9 ?
From a x86 perspective, I would say no, as it should not have v9
specific features, just some alignment/whatever that should work better
on a v9.

Comment 25 Martin Schlemmer (RETIRED) gentoo-dev 2003-09-15 12:05:45 UTC
And ?
Comment 26 Ferris McCormick (RETIRED) gentoo-dev 2003-09-15 13:53:04 UTC
I have not seen __sparc_v9__ mean 64-bit anywhere on sparc linux.  I routinely
use '-mcpu=ultrasparc' which does define __sparc_v9__, and the code is 32-bit.

glapi_sparc.S assumes __sparc_v9__ means 64-bit, and for some compilers it
seems to, but never for gcc on linux for sparc today.

-mcpu=v8 -mtune=v9 does not define __sparc_v9__

In xfree, -mcpu=v9 might or might not be filtered out be the ebuild.  If it is
not, and if it gets passed to the glapi.S routine, the code there assumes that
__sparc_v9__ implies 64 bit, which currently is not a correct assumption.

So, the *only* thing that sets __sparc_v9__ is -mcpu=v9 or an explicit
-D__sparc_v9__.  The only reason I messed with it at all was that I noticed that
no matter what flags you use to compile glx, on linux you should not get
into a situation where the source itself looks at __sparc_v9__ to see if the
compiler is generating 64-bit code, because the compiler is never compiling
64-bit code.

(At one point, what was setting __sparc_v9__ was me, chasing down the bug.  I
finally saw that the bug was independent of 64-bitness.  So my intent here was
to take it out, and to keep it out for the dispatch table stuff, no matter
how the user had CFLAGS set in make.conf.  The important thing is that the
dispatch table format and the code to patch the table agree on 64-bitness, and
I was forcing that, no matter what the Makefile finally decided on pasing in.)

xfree can use some v9-specific features, I believe, in the display driver
for the creator/elite video cards, but that is another matter.  So far as I
know, there is no v9 requirement for xfree.

What glapi_sparc.S really needs to know is whether or not we are in 64-bit user
mode, and right now, the answer to that is no.  However, 64-bit user support
for sparc linux is in the works, bit I have no idea how that will be communicated to routines like this one.

For this particular problem, so far as I know, there is no compiler problem,
nor is there a library problem, and glapi_sparc.S itself is fine.

The only problem is that the dispatch table in glapi_sparc.S needs to be
filled in on the fly, and for that to work, the table format and its initialization code have to agree on what it looks like.
Comment 27 Ferris McCormick (RETIRED) gentoo-dev 2003-09-15 14:46:45 UTC
Let me add a couple things which might help.

1.  I don't know how 64-bit userland is going to work for sparc, so I don't know
    what a proper approach to a long-term fix to make sure that the glapi_sparc.S
    templates agree with the code that fills them in.  The code that fills them in
    tries to guess what the instructions are, because it is rewriting them.  All
    that really matters is for it to guess right.  It would be much better to use
    something besides __sparc_v9__, because:

2.  For performance reasons, a user might NEVER want 64-bit linkages, but there
    are other reasons to use '-mcpu=v9':  that enables some v9-specific
    insructions for the assembler that you do want.  (One that comes to
    mind is exchange-add, which is an atomic test-and-set operation that
    the programmer can use for a very fast semaphore or mutual exclusion
    operation, and it can occur in user code.)  There are other v9-but-not-64-bit instructions that the compiler can generate with cpu=v9, and
    so far as I know, it does when appropriate.

3.  The short answer is that I really don't know how to set up the check in
    the setup process.  I think that gcc uses -mcpu=v9 to mean "sparc-v9
    architecture, but for linux, use 32-bit style addressing" and it seems that
    xfree is using it to mean "64-bit style addressing."

4.  So far as I can tell, this matters ONLY in glapi_sparc.S and the code
    that fills it in, and the ONLY place this ends up getting used seems to
    be in libGL.  At least, that's what 'find xc -name '*.[Ss]' tells me.

Sorry to make this so confusing.
Comment 28 Jason Wever (RETIRED) gentoo-dev 2003-09-15 17:31:24 UTC
Currently we don't have any plans for a 64 bit userland on sparc64, however it may be best to handle this fix as if we may someday.
Comment 29 Ferris McCormick (RETIRED) gentoo-dev 2003-09-16 05:00:32 UTC
I'll add one more thing which might help clear up the confusion.

If you are not actually building this on sparc and watching the build, you might
not have noticed that for whatever reason, the GL/glx build does not run
glapi_sparc.S through the compile in one step.  It does this instead:

rm -f glapi_sparc.i
/usr/bin/cpp -Dlinux -D__sparc__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_B
SD_SOURCE -D_SVID_SOURCE  -D_GNU_SOURCE    -DIN_GLX -D__ELF__ -DGLXEXT -DXF86DRI -DGLX_DIRECT_R
ENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -D__GLX_ALIGN64 -DUSE_SPARC_ASM  -I../../../exports/in
clude           -I../../../exports/include/X11          -I../../../include/extensions         -I../../../exports/include/GL            -I../../../lib/GL/glx           -I../../../extras/Mesa/
src             -I../../../extras/Mesa/src/X            -I../../../extras/Mesa/src/SPARC      -I../../../extras/Mesa/include           -I../../../lib/GL/include               -I../..
/../lib/GL/dri   glapi_sparc.S | \
grep -v '^\#' > glapi_sparc.i
rm -f glapi_sparc.o
gcc -c -x assembler  -mtune=v9 -o glapi_sparc.o glapi_sparc.i
rm -f glapi_sparc.i

And it uses a different set of flags for the preprocessing stage than for the
general gcc calls for the C-source.  Thus, it could happen (if the sparc setup
went wrong) that:

1.  glapi_sparc.S got compiled as 64-bit but the little template-fixer thought
    it was 32-bit (that's the new sparc.c); or,
2.  If we have -mcpu=v9, that the template-fixer thought glapi_sparc.S had
    64-bit linkages but the make file had set it up with 32-bit linkages.

I do not know why the Makefile gets set up that way, but it does, and that strikes me as pretty bad.  (The sunffb driver build for Creator & Elite video
potentially has the same problem, and I'll report on that another day.)  I
have verified that it is unnecessary (gcc can handle the .S file just fine)
for Linux, but for other compilers it might be required.

So, if you look at sparc.c, you will see that I have forced it to assume that
glapi_sparc.S was built with 32-bit linkages when it patches in the real dispatch table.  This meant that no matter how xfree finally decided to build
glapi_sparc.S, it HAD to use the 32-bit linkages, because sparc.c had no reliable way of figuring out what the build had decided on.

Originally, the sparc.c that I copied in used the same check for
__sparc_v9__ as glapi_sparc.S used, but for whatever reason, the configure
process screws that up if it allows -mcpu=v9 (as it should) but does not
propagate that to the cases where it decides to build the object in two stages.

I have no clue why the build gets set up this way; that is in the Imakefile
(which keys of the SparcArchitecture define) and imake's template for
assembler files (whereever that is).

SUMMARY:  With the build today, __sparc_v9__ could never be set for
          glapi_sparc.S, so I arranged glapi.c never to build 64-bit
          linkages, no matter what architecture the user was optimizing for.

          Once you do that, glapi_sparc.S has to be backfit so that no matter
          what the Configure chooses to use as flags for the preprocessor,
          you don't get 64-bit linkages.

          The problem is that however you patch the linkage code, you have to
          patch for the correct linkages, and the way the Makefile gets built,
          that is hard unless you just force it (it seems to me).

          I don't know how to do a general fix for this, because I don't
          know all places the "corrected" code has to keep running (beyond
          GenToo).

          All this is for is to make sure the API dispatch table gets filled
          in, and that the dispatch table and the code to patch the addresses
          in to the instructions agree on the table format.

Sorry to be so long winded; it becomes easier to see if you tear apart the
output from the make.  The right person to address this is whoever introduced
the -DUSE_SPARC_ASSEMB decision into xfree-4.3.0 (it is new with this release),
but I don't know who that is.  (I would hope that person wouldn't have to guess
what is supposed to be going on here ;).)
Comment 30 Jason Andryuk 2003-09-16 18:36:37 UTC
I've experienced this bug on an Ultra 2 Creator 3D.

I did some looking around, and I think the best thing would be to contact someone who actually knows what is going on.  The problem code is part of Mesa, so they would know what to do, I hope.

Here are links to the cvsweb for the sparc asm:
http://cvsweb.xfree86.org/cvsweb/xc/extras/Mesa/src/SPARC/
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mesa3d/Mesa/src/SPARC/

Progress has been made by mesa3d which is not included in xfree86.  Xfree86's last sync was to Mesa 4.0.1

I'm not sure what to look for in the files at the above sites, but there may be a fixed version already there.
Comment 31 Jason Andryuk 2003-09-17 15:34:50 UTC
I just tried to compile libGL using the suggestion of removing the USE_SPARC_ASM define.  I ran ebuild xfree-4.3.0-r2.ebuild compile and I stopped the compile after all the Makefiles were setup.  I then edited xc/lib/GL/glx/Makefile and Imakefile to replace 'ASM_DEFS = -DUSE_SPARC_ASM' with 'ASM_DEFS = '

I then ran make in /xc/lib/GL/glx/ followed by make in /xc/lib/GL/.  I got the following error.  There are a whole lot of the "multiple definition" lines, so I just pasted the ones at the end, the earlier ones go off the top of aterm's buffer.

: multiple definition of `glLoadTransposeMatrixf'
../../../lib/GL/glx/dispatch.o(.text+0xe130): first defined here
../../../lib/GL/glx/glapi_sparc.o(.data+0x33a4): In function `glMultTransposeMatrixd':
: multiple definition of `glMultTransposeMatrixd'
../../../lib/GL/glx/dispatch.o(.text+0xe17c): first defined here
../../../lib/GL/glx/glapi_sparc.o(.data+0x33b8): In function `glMultTransposeMatrixf':
: multiple definition of `glMultTransposeMatrixf'
../../../lib/GL/glx/dispatch.o(.text+0xe1c8): first defined here
../../../lib/GL/glx/glapi_sparc.o(.data+0x33cc): In function `glSampleCoverage':
: multiple definition of `glSampleCoverage'
../../../lib/GL/glx/dispatch.o(.text+0xe214): first defined here
/usr/lib/gcc-lib/sparc-unknown-linux-gnu/3.2.3/../../../../sparc-unknown-linux-gnu/bin/ld: cannot find -lXext
collect2: ld returned 1 exit status
+ rm -f libGL.so.1
+ ln -s libGL.so.1.2 libGL.so.1
+ rm -f ../../../exports/lib/libGL.so.1
+ cd ../../../exports/lib
+ ln -s ../../lib/GL/GL/libGL.so.1 .
rm -f libGL.so.1.2
mv -f libGL.so.1.2~ libGL.so.1.2
mv: cannot stat `libGL.so.1.2~': No such file or directory
make[1]: *** [libGL.so.1.2] Error 1
make[1]: Leaving directory `/var/tmp/portage/xfree-4.3.0-r2/work/xc/lib/GL/GL'
make: *** [all] Error 2

A little thinking and I also changed 'ASM_OBJS = glapi_sparc.o' to 'ASM_OBJS = ' and 'ASM_SRCS = glapi_sparc.S' to 'ASM_SRCS = '

But now, there is an error:
+ gcc -o ./libGL.so.1.2~ -shared -Wl,-Bsymbolic -Wl,-soname,libGL.so.1 ../../../lib/GL/glx/clientattrib.o ../../../lib/GL/glx/compsize.o ../../../lib/GL/glx/dispatch.o ../../../lib/GL/glx/eval.o ../../../lib/GL/glx/g_render.o ../../../lib/GL/glx/g_single.o ../../../lib/GL/glx/g_vendpriv.o ../../../lib/GL/glx/glapi.o ../../../lib/GL/glx/glthread.o ../../../lib/GL/glx/glxcmds.o ../../../lib/GL/glx/glxext.o ../../../lib/GL/glx/indirect_init.o ../../../lib/GL/glx/pixel.o ../../../lib/GL/glx/pixelstore.o ../../../lib/GL/glx/render2.o ../../../lib/GL/glx/renderpix.o ../../../lib/GL/glx/single2.o ../../../lib/GL/glx/singlepix.o ../../../lib/GL/glx/vertarr.o ../../../lib/GL/glx/xfont.o ../../../lib/GL/dri/XF86dri.o ../../../lib/GL/dri/dri_glx.o -lpthread -L../../../exports/lib -lXext -lX11 -ldl -lc
/usr/lib/gcc-lib/sparc-unknown-linux-gnu/3.2.3/../../../../sparc-unknown-linux-gnu/bin/ld: cannot find -lXext
collect2: ld returned 1 exit status
+ rm -f libGL.so.1
+ ln -s libGL.so.1.2 libGL.so.1
+ rm -f ../../../exports/lib/libGL.so.1
+ cd ../../../exports/lib
+ ln -s ../../lib/GL/GL/libGL.so.1 .
rm -f libGL.so.1.2
mv -f libGL.so.1.2~ libGL.so.1.2
mv: cannot stat `libGL.so.1.2~': No such file or directory
make[1]: *** [libGL.so.1.2] Error 1
make[1]: Leaving directory `/var/tmp/portage/xfree-4.3.0-r2/work/xc/lib/GL/GL'
make: *** [all] Error 2

So I modified xc/lib/GL/GL/Makefile to include /usr/X11R6/lib by setting "LDPRELIB = -L$(BUILDLIBDIR) $(INSTALLED_LIBS) -L/usr/X11R6/lib" (adding the "-L/usr/X11R6/lib" ).  This let libGL.so.1.2 build.  Modifying LDPRELIB should not be necessary if a full build is being preformed.  I believe it was necessary in this case since exports/lib does not contain any libraries.  I presume the make process places built libraries into exports/lib, and they were not present because I was only compiling libGL.so

I, like Ferris, don't know how you can have the ebuild automatically change the Makefile when the Makefiles are dynamically generated.
Comment 32 Jason Andryuk 2003-09-17 16:04:36 UTC
After looking around some, it looks like you can probably just modify xc/lib/GL/glx/Imakefile at the end of the unpack stage.  There you can blank out ASM_SRCS, ASM_OBJS, and ASM_DEFS.  Then when the Makefile is created, it will not have the variables defined, and the non-assembly versions will be used.

--- xc/lib/GL/glx/Imakefile.orig        2003-09-17 19:02:10.000000000 -0400
+++ xc/lib/GL/glx/Imakefile     2003-09-17 19:02:36.000000000 -0400
@@ -107,9 +107,9 @@
      ASM_DEFS = -DUSE_X86_ASM
 #endif
 #if defined(SparcArchitecture)
-     ASM_SRCS = glapi_sparc.S
-     ASM_OBJS = glapi_sparc.o
-     ASM_DEFS = -DUSE_SPARC_ASM
+     ASM_SRCS = 
+     ASM_OBJS = 
+     ASM_DEFS = 
 #endif
 
 #if GlxBuiltInXMesa
Comment 33 Ferris McCormick (RETIRED) gentoo-dev 2003-09-18 06:19:36 UTC
1.  Jason's (the_deuce's) suggestion builds a working library for me
    (at least, good enough for -glxgears- and -blender-):
     -edit Imakefile as per the_deuce (well, I used '-UUSE_SPARC_ASSM' because
      I am a little paranoid, and I wanted to keep track in my local copy that
      there was an option here that I explicitly wanted disabled.)
     -restore original link for glapi.c
     -make clean
     -make Makefile
     -make
     -cd .. ; make
     -hand install new libGL.so.1.2 fron xc/lib/GL/GL
(I have been keeping a completely built xfree in /usr/tmp/portage on U2 & U60)

2.  For glxgears, no performance difference that I can see.
3.  And much cleaner.

4.  This puts off Martin's question about __sparc_v9__, because if Mesa
    and other applications depend on this (-mcpu=ultrasparc) to mean
    64-bit linkages, while gcc (for linux) means ultrasparc architecture with
    32-bit linkages, there will be problems.  But that, I suppose, needs to
    be bounced to the gcc people and to the kernel 2.6 people...?
Comment 34 Jason Wever (RETIRED) gentoo-dev 2003-10-02 17:00:53 UTC
Created attachment 18634 [details, diff]
patch based on suggestions from Azarah
Comment 35 Jason Wever (RETIRED) gentoo-dev 2003-10-02 17:01:46 UTC
I tried a patch to the X source based on comments here and from Azarah on
IRC.  I have attached it here, but it did not remedy it for me.
Comment 36 Gregor Riepl 2003-11-27 14:12:08 UTC
thanks for the help guys
i patched my libGL and activated everything needed for OGL/DRI
XF86 reports all extensions active, especially the dri module and XFree86-DRI, but glxinfo still reports Direct Rendering: No
why?
what did I forget?
does it work at all?
75 fps on glxgears isn't bad for a 166MHz Ultra1, but i'd prefer a little more...
btw: i'm using -r3 and there wasn't any fix yet
had to do it myself
Comment 37 Ferris McCormick (RETIRED) gentoo-dev 2003-11-28 07:01:46 UTC
Following Gregor Riepl's advice, I have cross-referenced this entire bug to
xfree, at <http://bugs.xfree86.org/show_bug.cgi?id=923>

I hope I have done it in such a way that they can actually find this discussion.
And I hope this problem isn't somehow GenToo-only :-)
Comment 38 Ferris McCormick (RETIRED) gentoo-dev 2003-12-01 09:51:21 UTC
Please note also bug #852204 in the Mesa3D project at SourceForge.  This
addresses the '__sparc_v9__' problem.  Notice that Mesa (5.0.2) as a replacement
for xfree's version of Mesa-as-libGL seems to work fine as-is if you make all the
changes I noted in the 852204 report:  Change
#ifdef __sparc_v9__
to
#if ( (defined(__sparc_v9__) && !defined(__linux__) )
Comment 39 Ferris McCormick (RETIRED) gentoo-dev 2003-12-02 06:20:32 UTC
It looks as if Mesa is going to take care of the 32/64 bit user mode mismatch
which arises from '-mcpu=ultrasparc' when building libGL.  Please see

<https://sourceforge.net/tracker/?func=detail&atid=100003&aid=852204&group_id=3>

And please see <http://bugs.xfree86.org/show_bug.cgi?id=923> for more comments
regarding Mesa-xfree interface.

Comment 40 Ferris McCormick (RETIRED) gentoo-dev 2003-12-02 10:00:52 UTC
Here's a start on what's going on, and it sheds some light on the message:
=========
Xlib:  extension "XFree86-DRI" missing on display ":0.0".
=========

The dispatch table is initialized by Mesa; specifically, from the _math_init part
of Mesa initialization.  And, when GL is built for SPARC, it is told to build
it using Mesa.

It is also told to NOT to build this into libGL; rather, it puts it in the
module dri/ffb_dri.so

So, most of Mesa is not really part of libGL, and it never gets initialized.
(If you want to see the differences, compare xfree-glxinfo with Mesa-glxinfo:
=================
----
from xfree
----
ferris@lacewing:~/Packages/Snakes [390]% glxinfo
name of display: :0.0
Xlib:  extension "XFree86-DRI" missing on display ":0.0".
display: :0  screen: 0
direct rendering: No
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
client glx vendor string: SGI
client glx version string: 1.2
client glx extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
GLX extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.3 Mesa 4.0.4
OpenGL extensions:
    GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_border_clamp, 
    GL_ARB_texture_cube_map, GL_ARB_texture_env_add, 
    GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, 
    GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_color, 
    GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_texture_env_add, 
    GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, 
    GL_EXT_texture_lod_bias
glu version: 1.3
glu extensions:
    GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x27 24 tc  1 24  0 r  y  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None
0x28 24 tc  1 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16  0  0 0 None
0x29 24 tc  1 24  0 r  y  .  8  8  8  8  0 16  8 16 16 16 16  0 0 None
0x2a 24 tc  1 24  0 r  .  .  8  8  8  8  0 16  8 16 16 16 16  0 0 None
0x2b 24 dc  1 24  0 r  y  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None
0x2c 24 dc  1 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16  0  0 0 None
0x2d 24 dc  1 24  0 r  y  .  8  8  8  8  0 16  8 16 16 16 16  0 0 None
0x2e 24 dc  1 24  0 r  .  .  8  8  8  8  0 16  8 16 16 16 16  0 0 None
0x2f  8 pc  1 24  0 c  y  .  0  0  0  0  0 16  0  0  0  0  0  0 0 None
0x30  8 gs  1 24  0 c  y  .  0  0  0  0  0 16  0  0  0  0  0  0 0 None
0x31  8 sg  1 24  0 c  y  .  0  0  0  0  0 16  0  0  0  0  0  0 0 None
==============

=====
---
from Mesa:
---
./glxinfo | more
name of display: :0.0
display: :0  screen: 0
direct rendering: No
server glx vendor string: Brian Paul
server glx version string: 1.4 Mesa 5.0.2
server glx extensions:
    GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap, 
    GLX_MESA_release_buffers, GLX_ARB_get_proc_address, GLX_EXT_visual_info, 
    GLX_EXT_visual_rating, GLX_SGI_video_sync, GLX_SGIX_fbconfig, 
    GLX_SGIX_pbuffer
client glx vendor string: Brian Paul
client glx version string: 1.4 Mesa 5.0.2
client glx extensions:
    GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap, 
    GLX_MESA_release_buffers, GLX_ARB_get_proc_address, GLX_EXT_visual_info, 
    GLX_EXT_visual_rating, GLX_SGI_video_sync, GLX_SGIX_fbconfig, 
    GLX_SGIX_pbuffer
GLX extensions:
    GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap, 
    GLX_MESA_release_buffers, GLX_ARB_get_proc_address, GLX_EXT_visual_info, 
    GLX_EXT_visual_rating, GLX_SGI_video_sync, GLX_SGIX_fbconfig, 
    GLX_SGIX_pbuffer
OpenGL vendor string: Brian Paul
OpenGL renderer string: Mesa X11
OpenGL version string: 1.4 Mesa 5.0.2
OpenGL extensions:
    GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multisample, 
    GL_ARB_multitexture, GL_ARB_point_parameters, GL_ARB_shadow, 
    GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, 
    GL_ARB_texture_compression, GL_ARB_texture_cube_map, 
    GL_ARB_texture_env_add, GL_ARB_texture_env_combine, 
    GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, 
    GL_ARB_texture_mirrored_repeat, GL_ARB_transpose_matrix, 
    GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, 
    GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, 
    GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, 
    GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, 
    GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_histogram, 
    GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_paletted_texture, 
    GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal, 
    GL_EXT_secondary_color, GL_EXT_separate_specular_color, 
    GL_EXT_shadow_funcs, GL_EXT_shared_texture_palette, 
    GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_subtexture, 
    GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, 
    GL_EXT_texture_env_add, GL_EXT_texture_env_combine, 
    GL_EXT_texture_env_dot3, GL_EXT_texture_object, GL_EXT_texture_lod_bias, 
    GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, 
    GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, 
    GL_HP_occlusion_test, GL_IBM_rasterpos_clip, 
    GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, 
    GL_MESA_pack_invert, GL_MESA_resize_buffers, GL_MESA_ycbcr_texture, 
    GL_MESA_window_pos, GL_NV_blend_square, GL_NV_point_sprite, 
    GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_NV_vertex_program, 
    GL_NV_vertex_program1_1, GL_SGI_color_matrix, GL_SGI_color_table, 
    GL_SGIS_generate_mipmap, GL_SGIS_pixel_texture, 
    GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, 
    GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_pixel_texture, 
    GL_SGIX_shadow, GL_SGIX_shadow_ambient
glu version: 1.3
glu extensions:
    GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x27 24 tc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16  0  0 0 None
0x28 24 tc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16 16  0 0 None
0x29 24 tc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16 16  0 0 None
0x2a 24 tc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16 16  0 0 None
0x2b 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16 16  0 0 None
0x2c 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16 16  0 0 None
0x2d 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16 16  0 0 None
0x2e 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16 16  0 0 None
0x2f  8 pc  0  8  0 r  y  .  2  3  3  0  0 16  8 16 16 16 16  0 0 None
0x30  8 gs  0  8  0 r  y  .  2  3  3  0  0 16  8 16 16 16 16  0 0 None
0x31  8 sg  0  8  0 r  y  .  2  3  3  0  0 16  8 16 16 16 16  0 0 None
======)

NOW, if you replace 'Load  "dri"'
in XF86Config with this:
  SubSection  "dri"
  Option   "ffb_dri"  "true"
  EndSubSection
you seem to get Xfree-DRI extension added, although glxinfo still does not know
about it.  So, it lookg like Mesa still is not initialized.

I suspect that there is a clue in the note "server glx vendor string: SGI"

I am starting to sort-of see what is going on here, but I don't see yet what is
supposed to be happening.  I will next see what happens if you tell it to
build the ffb_dri stuff into libGL instead of into an xfree module, but something about this is not looking right.

What am I missing here?
Comment 41 Ferris McCormick (RETIRED) gentoo-dev 2003-12-03 09:01:06 UTC
Please note a very long summary of what seems to be going on here at
<http://bugs.xfree86.org/show_bug.cgi?id=923> comment #11.

Is any of this starting to make sense?
Comment 42 Ferris McCormick (RETIRED) gentoo-dev 2003-12-04 10:31:50 UTC
Created attachment 21699 [details, diff]
Patch in GLapi dispatch table initialization for xfree-libGL

See also <http://bugs.xfree86.org/show_bug.cgi?id=923>
See also
<https://sourceforge.net/tracker/?func=detail&atid=100003&aid=852204&group_id=3>

Assume also the 813 #ifdef changes
#ifdef __sparc_v9__ ==> #if (defined(__sparc_v9__) && !defined(__linux__) )
to the Mesa source in xfree.

Assume you are working within xfree-4.3.99.16.

Then, this little patch (to xc/lib/GL/glx/glxext.c) seems to give a version of
libGL which can handle glxinfo, glxgears, blender, and crystal-space.

This version of libGL doesn't give the annoying "XFree86-DRI extension missing"

message anymore (no performance improvement, though.)

However, since I don't actually know how glx works, this needs a lot of testing

by people who actually use libGL...  This proposal is based on intuition, not
knowledge.

Regards,
Ferris
Comment 43 Ferris McCormick (RETIRED) gentoo-dev 2003-12-04 15:14:17 UTC
I should add that my testing has been limited to systems (U2, U60) with Elite
video cards.  Thus, the only driver used has been sunffb, and sunffb-Elite does
NOT use xfree's dri module.  So there is a lot of stuff that needs checking.

But the effect of this patch is just to move the initialization from 'glapi.c'
(which is part of Mesa) to glxext.c (which is from SGA, I believe.)

This shouldn't matter, but I can't verify it.  (With enough time, I can play with
the Creator path through sunffb, but not right away.)
Comment 44 Ferris McCormick (RETIRED) gentoo-dev 2003-12-05 15:42:42 UTC
Three comments further:

1.  The brace on the next-to-last line of the patch should be moved up to the
    other side of the #else three lines above it (or glext.c will not compile on
    non-sparc systems);

2.  This approach does work for sunffb-Creator (I retrofit the stuff back into
    xfree-4.3.0-r3 for the Creator test.  The original test was against
    latest xfree at xfree's perfectly reasonable request.)  

3.  This is more of a user-type question:  Dawes in the response to the
    corresponding bug report at xfree (comment #42 for reference) believes that
    the xfree module ffb_dri.so in /usr/X11R6/lib/modules/dri should be
    initializing the libGL glAPI table.  But I don't see it.

    Where in the documentation can I find how to even use this module?  It has
    to be something in the XF86Config file, but I can't find it documented, and
    a source scan of the entire xfree (xc) build tree does not turn up anything
    useful to me.  I can't see that the libdri (dri extension), the logical
    owner, does anything with it.

    For this to work, it has to be linked into the libGL address space, and it
    has to preempt the libGL initialization, but it has to have libGL present
    because that's where the unitialized dispatch table is to begin with.
    (ffb_dri.so does not have it at all.)  I'm completely missing something
    pretty basic here.

    HELP?!!?
Comment 45 Ferris McCormick (RETIRED) gentoo-dev 2003-12-06 08:20:18 UTC
Created attachment 21789 [details, diff]
Corresponding patch for xc/lib/GL/glx/glxext.c, zfree-4.3.0-r3

Attached patch will apply to xc/lib/GL/glx/glxext.c in xfree-4.3.0-r3.
Along with the corresponding #ifdef __sparc_v9__ changes (only 600 or so
in this version), the resulting library appears to work.
Comment 46 Ferris McCormick (RETIRED) gentoo-dev 2003-12-06 11:02:57 UTC
And, in case it is not clear from all my ramblings:  There are three modules
affected by this (either by the change to glxext.c, or by the 600+ #ifdef
changes in xc/extras/Mesa/src[/SPARC]).
1.  libGL.so.1.2 itself
2.  ffb_dri.so (built in xc/lib/GL/mesa/src/drv/ffb/ffb_dri.so and installed
    in /usr/X11R6/lib/modules/dri
3.   libOSMesa built in /xc/lib/GL/mesa/src/OSmesa/libOSMesa.so.4.0 and installed
    in /usr/X11R6/lib
Because the glx extension is not built with -DUSE_SPARC_ASM, it and its helper
libGLCore.a do not change.

So, a fair test needs to have the 3 *.so modules from lib/GL put into
production.  I don't think anything else in the xfree installation is changed.
Comment 47 Ferris McCormick (RETIRED) gentoo-dev 2003-12-08 08:26:11 UTC
Please review the last few comments at
<http://bugs.xfree86.org/show_bug.cgi?id=923>
for sanity, but I am pretty sure that 2003-12-0[46] patches are pretty close to
what is required to fix this for current and proposed xfree-4.3.xx

Again, for this to work, all of the #ifdef __sparc_v9__ tests in
xc/extras/Mesa/src[/SPARC] need to be sometning like
#if (defined(__sparc_v9__) && (!defined(__linux__) || defined(__sparc_linux_64__)))

To recap the comments in the corresponding xfree bug 923:

1.  This initialization has to happen through software because the assember
    loader combination either can't or won't for sparc (&_glapi_Dispatch gets
    split across 2 instructions.)
2.  This is a local address (to libGL).  The server can provide linkages within
    the table, but not the address of the table itself.  So the xfree
    speculation that the server should set this up seems wrong.
3.  This patch occurs as part of the glXInitialization which I think always
    has to happen before libGL can do anything, no matter who puts the
    address of the dispatch vector into _glapi_Dispatch.

Does this make any sense?
Regards,
Comment 48 Ferris McCormick (RETIRED) gentoo-dev 2003-12-08 11:27:42 UTC
Xfree (at bug 923) has taken this patch.  I sure hope it's right, because I'll
have to crawl under rocks someplace if I've really screwed up after all of this.
Comment 49 Ferris McCormick (RETIRED) gentoo-dev 2003-12-09 08:47:49 UTC
Created attachment 21930 [details]
Automate the #ifdef --> #if (defined(_sparc_v9__).... changes to xc/extras/Mesa

Running this script in the work directory where you are building xfree will
patch the (known) Mesa files containing #ifdef __sparc_v9__

As long as Mesa does not add or delete from the set of files using this flag,
the script should work regardless of what version of xfree you are playing
with.

My test looked like:

cd /var/tmp/portage/xfree-4.3.0-r3/work
cp ~ferris/PATCH_V9 .
./PATCH_V9
Comment 50 Ferris McCormick (RETIRED) gentoo-dev 2003-12-09 09:01:06 UTC
The last attachment is a little bash script to complete the automation of a
possible fix for this.  It is a little collection of '"sed's" which edit the
Mesa sources which depend on Sparc assembler to change

#ifdef __sparc_v9__ ==>
#if (defined(__sparc_v9__) && (!defined(__linux__) || defined(__linux_64__)))

where __linux_64__ is just something I made up to indicate that if we are in
64-bit usermode for sparc, we don't want to disable the 64-bit addressing.

So, an automated fix which apparently works for xfree-4.3.0-r3 looks like
1.  Unpack sources
2.  cp glx.patch var/tmp/portage/xfree-4.3.0-r3/work/
    cp PATCH_V9 var/tmp/portage/xfree-4.3.0-r3/work/
  (or whatever you call them)
3.   cd /var/tmp/portage/xfree-4.3.0-r3/work
4.   patch -b -z - -p0 < glx.patch
5.   ./PATCH_V9
6.  cd xc and manually verify that the changes you wanted are present
7.  Build & test

Regards,
Ferris
Comment 51 Sven Blumenstein (RETIRED) gentoo-dev 2004-03-30 02:29:45 UTC
Just for the record, glxgears works fine on my Ultra5 with the newest XFree.

[ebuild   R   ] x11-base/xfree-4.3.99.902-r2  -(3dfx) -cjk -debug -doc -ipv6 -nls +pam -sdk -static +truetype -xml2

bazik@darwin bazik $ glxgears 
307 frames in 5.0 seconds = 61.400 FPS
320 frames in 5.0 seconds = 64.000 FPS
320 frames in 5.0 seconds = 64.000 FPS
320 frames in 5.0 seconds = 64.000 FPS
320 frames in 5.0 seconds = 64.000 FPS

Not very fast tho ;) 
Comment 52 Ferris McCormick (RETIRED) gentoo-dev 2004-03-30 05:12:41 UTC
Thanks for the information.  I'll try to look at it in the next day or so.  How
fast is your CPU and what kind of graphics card are you using?  Because no, that's
not very fast at all.  (Unless you have about a 176MHz CPU).
Comment 53 Sven Blumenstein (RETIRED) gentoo-dev 2004-03-30 05:58:23 UTC
> How fast is your CPU and what kind of graphics card are you using?  

440 Mhz Ultrasparc IIi and the onboard 4 MB ATI card.

direct rendering is disabled, so it looks like it useses software rendering. How can I enable direct rendering? Never had use for it on Linux ;)

glxinfo:

bazik@darwin bazik $ glxinfo
name of display: :0.0
display: :0  screen: 0
direct rendering: No
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, 
    GLX_SGI_make_current_read
client glx vendor string: SGI
client glx version string: 1.2
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, 
    GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, 
    GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, 
    GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
    GLX_SGIX_visual_select_group
GLX extensions:
    GLX_ARB_get_proc_address, GLX_EXT_import_context, GLX_EXT_visual_info, 
    GLX_EXT_visual_rating, GLX_SGI_make_current_read
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.4 Mesa 5.0.2
OpenGL extensions:
    GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multitexture, 
    GL_ARB_point_parameters, GL_ARB_shadow, GL_ARB_shadow_ambient, 
    GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map, 
    GL_ARB_texture_env_add, GL_ARB_texture_env_combine, 
    GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, 
    GL_ARB_texture_mirrored_repeat, GL_ARB_transpose_matrix, 
    GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, 
    GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, 
    GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_copy_texture, 
    GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, 
    GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, 
    GL_EXT_secondary_color, GL_EXT_separate_specular_color, 
    GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, 
    GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, 
    GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, 
    GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, 
    GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_texture_rectangle, 
    GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_texture_mirror_once, 
    GL_ATI_texture_env_combine3, GL_IBM_texture_mirrored_repeat, 
    GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_NV_blend_square, 
    GL_NV_texgen_reflection, GL_NV_texture_rectangle, GL_SGIS_generate_mipmap, 
    GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, 
    GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow, 
    GL_SGIX_shadow_ambient
glu version: 1.3
glu extensions:
    GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x23 16 tc  0 16  0 r  y  .  5  6  5  0  0 16  0  0  0  0  0  0 0 None
0x24 16 tc  0 16  0 r  y  .  5  6  5  0  0 16  8 16 16 16  0  0 0 None
0x25 16 tc  0 24  0 r  y  .  5  6  5  8  0 16  8 16 16 16 16  0 0 None
0x26 16 tc  0 24  0 r  .  .  5  6  5  8  0 16  8 16 16 16 16  0 0 None
0x27 16 dc  0 16  0 r  y  .  5  6  5  0  0 16  0  0  0  0  0  0 0 None
0x28 16 dc  0 16  0 r  y  .  5  6  5  0  0 16  8 16 16 16  0  0 0 None
0x29 16 dc  0 24  0 r  y  .  5  6  5  8  0 16  8 16 16 16 16  0 0 None
0x2a 16 dc  0 24  0 r  .  .  5  6  5  8  0 16  8 16 16 16 16  0 0 None
Comment 54 Ferris McCormick (RETIRED) gentoo-dev 2004-03-30 09:12:05 UTC
So far as I can tell, xfree doesn't build direct rendering support for the ATI
(mach64?) card.  (Of course, what it "builds" for the Creator is flat out broken.)

That said, though, in your Config file's Modules section, you ought to be able
to Load "dri"
   Load "drm"
   Load "glx"
and your driver should use as much of this as it can.

There are several ati-related drivers, and some of them do talk about DRM.  They
seem to be for radeon stuff, though, and I really don't know anything about ati
cards at all.

I'll look more closely at it in a day or so.  I've been tied up on some other
things for the last two or three days.
Comment 55 Donnie Berkholz (RETIRED) gentoo-dev 2004-03-30 09:20:14 UTC
mach64 cards should be able to use direct rendering, at least on x86. Don't know of any special issues on sparc. You'll need the kernel module for mach64 though.
Comment 56 Ferris McCormick (RETIRED) gentoo-dev 2004-04-01 07:10:12 UTC
As Sven Blumenstein suspected, the final patch and set of #ifdefs are present
in xfree-4.3.99.902-r2:  You neither need to nor want to apply them by hand if
you are testing this version.

(Notice that the #ifdef version is testing
#if  defined(__sparc_v9__) && !defined(__linux__)
so if you are testing a 64-but userland version of xfree, you need to unapply them.  But why would you want a 64-bit version of libGL???)
Comment 57 Ferris McCormick (RETIRED) gentoo-dev 2004-04-19 12:31:48 UTC
Created attachment 29642 [details, diff]
Patch to today's cvs ebuilds for -r5, -r6 which fixes this bug.

As requested by spyderous, I am attaching a patch file against today's cvs
version of the ebuilds for 4.3.0-r5, 4.3.0-r6 which should close this bug.

For reference, I shall next attach the patch file these (patched) ebuilds use,
but it is the same as number 21789.
Comment 58 Ferris McCormick (RETIRED) gentoo-dev 2004-04-19 12:37:31 UTC
Created attachment 29643 [details, diff]
The patch file referenced ain the previous attachment as ${FILESDIR}/sparc-glx-4.3.0-patch

This is the file from which the patched ebuilds do their 'epatch' in my test
tree.
It should be the same as 21789.
Comment 59 Ferris McCormick (RETIRED) gentoo-dev 2004-04-19 12:41:23 UTC
At spyderous's request, reassign to xfree@gentoo.org for final processing.
From a sparc point of view, this bug is fixed (i.e., unless spyderous needs
anything more from me, I am finished with it.)
Comment 60 Donnie Berkholz (RETIRED) gentoo-dev 2004-04-19 14:07:53 UTC
Ferris, could you convert all that sed stuff in the ebuild into a source patch and integrate it with the other source patch? I didn't realize it was so extensive.
Comment 61 Ferris McCormick (RETIRED) gentoo-dev 2004-04-19 15:29:23 UTC
Sure, I'll do it tomorrow.  I did it with sed because as a patch, it's huge.
(It'll take me about 5 minutes to do it, but I don't have the source unpacked on
the system I'm on now).  You will have the entire fix in one big patch file.

Regards,
Comment 62 Ferris McCormick (RETIRED) gentoo-dev 2004-04-20 05:12:16 UTC
Created attachment 29686 [details, diff]
Entire fix for sparc, xfree-4.3.0, as one big patch file

Donnie,
  Here's the complete fix as one big patch.  It forces dispatch table
initialization and makes sure never to use 64-bit user mode in Mesa.

This really only matters to sparc, and it is for 4.3.0 only.  It is already
present in the 4.3.99.902-r2 snapshot, and it is present in the
xorg-x11-6.7.0 branch (which is where I am going to concentrate), although in a

somewhat cleaner form (so far as the sparc_v9 checks go).

Hope this helps.
Regards,
Ferris
Comment 63 Ferris McCormick (RETIRED) gentoo-dev 2004-05-29 16:42:03 UTC
I am taking this bug back in preparation of closing it.

The problem described here is fixed in xorg-x11, essentially as shown in the current patch attachment.

xorg-x11 is now stable on sparc and is the default for new installations.  Consequently, this bug should not show up again.

I am going to hold it for a couple days, and if nothing unexpected turns up, I am going to close it as fixed in xorg-x11.
Comment 64 Ferris McCormick (RETIRED) gentoo-dev 2004-06-07 11:09:13 UTC
This bug is fixed in xorg-x11-6.7.0, which has been stable for sparc for a little over a week with no problems reported.

xorg-x11 is currently stable also for ppc, arm, and amd64.  Spyderous's 3 June ChangeLog entry indicates
that probably xorg-x11 should be ready to go stable pretty much across the board.

Therefore, I am marking this as fixed.  There is no need to apply the patch to
xfree-4.3.0-r5, because xorg-x11 is a stable alternative in which the patch is already present.