Mesa linux-dri or linux-dri-x86 Won't Make

Muraii · 09-13-2006, 02:39 PM

Hi,

I've been trying for a few days to get DRI and Mesa installed for an ATI Radeon 9000. After quite a bit of trying to install to /usr/lib/ rather than the default /usr/local/lib/, following the documentation, I just let libdrm be installed in the default location.

I had thought that that was the only thing stopping Mesa from making correctly, but alas that's not so. I have made sure to have $PKG_CONFIG_PATH updated correctly, so the Mesa makefile can find libdrm; I've made sure I have glxphoto.h in the proper directory, per the documentation; and I've adjusted the default DRI_DIRS to include only radeon. So far as I can tell, I have everything set as completely as is needed.

However, upon issuing either

Code:

~/Mesa/$ make linux-dri-x86

or just

Code:

~/Mesa/$ make linux-dri

the Mesa libraries won't make. Further, each time I've tried something different, e.g. fixing the $PKG_CONFIG_PATH when I found out it wasn't updated, I try to make and am informed to

Code:

make realclean

before making again with changed configuration. Running that puts that shell in what appears to be an endless loop, where make and makedepend end up sharing anywhere between 30% and 80% of my CPU cycles. I see the same stuff thrown to stdout over and over, typically about a variety of header files. It repeatedly dies looking for matypes.h:

Code:

makedepend: warning:  /usr/include/gnu/stubs.h:  non-portable whitespace encountered at line 7
makedepend: warning:  x86/common_x86_asm.S, line 42: cannot find include file "matypes.h"
        not in matypes.h
        not in x86/matypes.h
        not in ../../include/matypes.h
        not in ../../src/mesa/matypes.h
        not in ../../src/mesa/main/matypes.h
        not in ../../src/mesa/glapi/matypes.h
        not in ../../src/mesa/math/matypes.h
        not in ../../src/mesa/tnl/matypes.h
        not in ../../src/mesa/shader/matypes.h
        not in ../../src/mesa/shader/grammar/matypes.h
        not in ../../src/mesa/shader/slang/matypes.h
        not in ../../src/mesa/shader/slang/OSDependent/Linux/matypes.h
        not in ../../src/mesa/shader/slang/OGLCompilersDLL/matypes.h
        not in ../../src/mesa/swrast/matypes.h
        not in ../../src/mesa/swrast_setup/matypes.h
        not in /usr/local/lib/gcc-include/matypes.h
        not in /usr/include/matypes.h
        not in /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/include/matypes.h

I fixed the non-portable whitespace, which, as I'd expected, doesn't really help anything.

A little digging seems to indicate matypes.h is supposed to be in the Mesa tree (see
http://cvsweb.xfree86.org/cvsweb/xc/...le.X11?rev=1.2) in the X86 directory. The only thing I have is the gen_matypes.c. Does this

Code:

# need some special rules here, unfortunately
x86/matypes.h: main/mtypes.h tnl/t_context.h x86/gen_matypes.c
	$(CC) $(INCLUDE_DIRS) $(CFLAGS) x86/gen_matypes.c -o x86/gen_matypes
	./x86/gen_matypes > x86/matypes.h
	#rm -f x86/gen_matypes x86/*.o

mean that make is supposed to create matypes.h? What might stop that?

To recap:

(1) Mesa won't make, though I've installed libdrm appropriately (as far as I can tell), and updated the path variable so Mesa can find libdrm. I have glxproto.h located correctly. I've tried making linux-dri-x86 and linux-dri, with no discernible variation in results.

(2) Possibly (logically) related, upon a failed make attempt, I'm prompted to make realclean, which starts what seems an infinite loop tied to a missing matypes.h header file. I assume that this file might be missing because, well, the make wasn't successful far enough to have generated it, if in fact it's generated during the making of Mesa.

Any light you can shed on this would be appreciated.

Daniel

Muraii · 09-14-2006, 11:42 PM

The entire episode here is due to following the dri.freedesktop.org/wiki/Building recommendation of getting Mesa via cvs. After doing this over and over, as the only means of recovering from the make realclean loop, I found, via the Mesa-users mailing list, that someone else was having trouble with the cvs source. They downloaded bzipped source, and things were pretty. I experienced the same thing.

Of course, now I've compiled and installed the DRI/DRM stuff, and put Mesa files where (I think) they're supposed to go, and reinstalled X after deleting libglx (thinking it was somehow tied to the nVidia drivers I was deleting)...and no direct rendering. If I leave the old radeon_drv.o in, X will at least load; but I get 93 FPS. If I use the new radeon_drv.o that I built while building DRM, X won't load at all.

The DRI Troubleshooting page shows me the error glxinfo gives me, though mine's about r200_dri.so, which is installed and old, older than my libdrm.a, etc. There is no r200_dri.so in the drivers I build via DRM, so I can't replace it with a newer one. I'm just at a loss.

I don't want to use the proprietary ATI drivers, but if I need to, I will.

Muraii · 09-15-2006, 12:19 AM

Um, well, here's the thing: when I was compiling Mesa, I removed a bunch of drivers from linux-dri, thinking I'd keep it lean. I'd never need the i810, or savage, or r128, or r200, right? Wait, did I say r200? Yes, yes I did.

Compiled that, stuck it in the right directory, and now direct rendering works. I'm only getting 400 FPS on glxgears @ 1024x768, and I think I should be getting a bit more (I've heard tales of about 3000). But that'll be some tweaking I can do later, I guess.