Bugzilla Bug 61147

The glide ebuild doesn't begin to work on sparc, even though it has the "sparc"
keyword. The glide configure script seems to assume a 486 CPU if it can't
figure out otherwise, which will obviously fail if you're using a sparc
compiler. There is a fix already in the ebuild to correct this behavior on
alpha. I have extended the fix to include sparc in the patch attached. Glide
still doesn't fully build for me, but that is caused by an unrelated bug that
has already been filed here - without the fix in this bug, it will not build at
all on sparc.

Reproducible: Always
Steps to Reproduce:
On a Gentoo/SPARC system, emerge glide-v3.
Actual Results:  
The build stopped after a GCC error complaining about the use of the -m486
flag.

Expected Results:  
It should have compiled with sparc-related flags and not caused an error.

Created an attachment (id=37864) [edit]
Fix for glide-v3 ebuild so that it compiled with correct flags.

Just for curiosity sake, do you have a working device you can test glide
against to show that it does work even with this patch?

Well, I have a PCI Voodoo Banshee card and a Sun Ultra 10. The Banshee card
works beautifully in X. It's very well behaved on sparc, and I've had it
running with full hardware 3d rendering using glide on x86 Linux in the past.

This patch alone doesn't allow glide to build on sparc. At the least another
patch from bug #54999 is needed (it doesn't seem to be in portage yet?), maybe
more.

Sorry for getting back to you so late.

OK, so after testing your patch, it looks like the problem we run into here is that SPARC doesn't have a sys/io.h.  The compile error that shows now with your patch is as follows;

gcc -DX11 -fomit-frame-pointer -funroll-loops -fexpensive-optimizations -ffast-
math -DBIG_OPT -Wall -I../../../../h5/glide3/src -I../../../h5/incsrc -I../../..
/../h5/incsrc -I../../../../h5/minihwc -I. -I../../../../swlibs/fxmemmap -I../..
/../../swlibs/fxmisc -I../../../../swlibs/newpci/pcilib -I../../../../swlibs/tex
us2/lib -O6 -mcpu=ultrasparc -mtune=ultrasparc -O2 -g -pipe -Wp,-MD,.deps/fxlinu
x.pp -c ../../../../swlibs/newpci/pcilib/fxlinux.c  -fPIC -DPIC -o .libs/fxlinux
.o            
../../../../swlibs/newpci/pcilib/fxlinux.c:29:20: sys/io.h: No such file or directory
../../../../swlibs/newpci/pcilib/fxlinux.c: In function `pciInitializeLinux':
../../../../swlibs/newpci/pcilib/fxlinux.c:186: warning: implicit declaration of function `iopl'
../../../../swlibs/newpci/pcilib/fxlinux.c: In function `pciPortInByteLinux':
../../../../swlibs/newpci/pcilib/fxlinux.c:248: warning: implicit declaration of function `inb'
../../../../swlibs/newpci/pcilib/fxlinux.c: In function `pciPortInWordLinux':
../../../../swlibs/newpci/pcilib/fxlinux.c:268: warning: implicit declaration of function `inw'
../../../../swlibs/newpci/pcilib/fxlinux.c: In function `pciPortInLongLinux':
../../../../swlibs/newpci/pcilib/fxlinux.c:288: warning: implicit declaration of function `inl'
../../../../swlibs/newpci/pcilib/fxlinux.c: In function `pciPortOutByteLinux':
../../../../swlibs/newpci/pcilib/fxlinux.c:308: warning: implicit declaration of function `outb'
../../../../swlibs/newpci/pcilib/fxlinux.c: In function `pciPortOutWordLinux':
../../../../swlibs/newpci/pcilib/fxlinux.c:324: warning: implicit declaration of function `outw'
../../../../swlibs/newpci/pcilib/fxlinux.c: In function `pciPortOutLongLinux':
../../../../swlibs/newpci/pcilib/fxlinux.c:340: warning: implicit declaration of function `outl'
make[3]: *** [fxlinux.lo] Error 1
make[3]: Leaving directory `/mnt/sda/portagetmp/portage/glide-v3-3.10-r4/work/glide3x/build/swlibs/newpci/pcilib'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/mnt/sda/portagetmp/portage/glide-v3-3.10-r4/work/glide3x/build/swlibs/newpci'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/mnt/sda/portagetmp/portage/glide-v3-3.10-r4/work/glide3x/build/swlibs'
make: *** [all-recursive] Error 1


Now in looking around in the glibc headers to see if there is a viable alternative, it doesn't appear that we have one.  If anyone else has any suggestions as to how to proceed, please feel free to post.

Try adding the patch in bug #54999 for fxlinux.c, looks like it might fix the
problems with the inb/outb and friends.

Bryan, what's the deal w/ bug #54999? You say it's in portage, they say it's
maybe not.

The patch is definitely in portage (ChangeLog entry 24 Jun 2004, ebuild
revision 1.6), but all it does is fix the number of arguments sent to ioctl().
It should have no effect on the errors reported here.

asm/io.h work for sparc folks?

Created an attachment (id=44133) [edit]
glide-v3-3.10-fix-headers-sparc.patch

This is a one-liner to change #include <sys/io.h> to <asm/io.h> as suggested by
Donnie. Sparc testing needed, drop it into files/ and add 'epatch
${FILESDIR}/${P}-fix-headers-sparc.patch' below the other two epatch lines.
Thanks in advance for feedback.

I had tried that but it bombed horribly as it appears the function calls with
the same names dont' quite appear to want the same things.  Also you are still
missing iopl in asm-sparc/io.h or asm-sparc64/io.h.  Also regular sys/io.h in
/usr/include comes from the glibc package.

Maybe the real bug is using non-portable crap, and it needs to be
re-implemented or something. Anyone up to it?

If no one has any objections, I'd like to mark this -sparc as it appears that
it is broken on SPARC regardless of current keywords.  Chances are these
keywords showed up from back in the dark ages of keywording and were never
actually tested on SPARC before receiving the SPARC keyword.

If it doesn't work, then please do. I don't have hardware for that arch, so I
won't argue.

Now masked on SPARC.  If the code for this ever gets cleaned up, feel free to
ask us about it again.

Alph ais failing for similar reasons; (in h3/minihwc/linhwc.c) hitting some x86
asm - I know glide-v3 has built on the Alpha few years ago (not Gentoo) - so I
know it was possible.

No longer keyworded, if you have a working patch then reopen this bug. Thanks.