Xorg 7.1 + Mesa 6.5 + uClibc 0.9.28 + gcc 4.1.1, extensions/libglx.so lockups

[Rupert Mazzucco]

> > > I renamed the extensions/libglx.so file to another name so that
> > > it would not be found and therefore could not load, and Xorg starts.
> > >
> > > I cannot figure out where to begin to look for this problem. 

Best way to start is to redirect X stderr to some file so you can read
it after rebooting, like X > x.err 2>&1  This will often give additional
info not in Xorg.0.log.

I compiled X11R7.1 (xorg-server-1.1.1, actually) on the same system you
have, and had hangups with dri and glx, too.  I was able to hunt them down
and found they have one of two sources:

Firstly, the X source, and the Mesa-related stuff in particular, appears to
contain numerous logic errors that show up when you compile with "non-standard"
flags.  Modules will end up containing undefined symbols, and you'll see
messages like "libbla.so: Symbol 'foo' undefined" on stderr before the system
hangs.  I had this with "XFree86DGAExtensionInit" after I had disabled DGA
(--disable-dga), with "noPanoramiXExtension" after --disable-xinerama, and with
"assert".

The only way to remove these is to hunt them down in the source and somehow
fix the source.  In the first case, I found that "XFree86DGA" remained defined
in include/{xorg-server.h,dix.config.h,do-not-use-config.h} and the solution
was simply to remove these definitions.  In the second case, it turned out
that there is a logic glitch in hw/xfree86/dri/dri.c line 147 where the symbol
was implicitly defined although it shouldn't be. Solution: remove the
"if(!noPanoramiXExtension){}" check.  In the third case, a file, can't remember
which one, simply had used an assert statement without bothering to include
<assert.h>, solution: add #include <assert.h> at the top.  You get the idea.
Find -name *.c -exec grep -H "foo" {} \; is your friend for this task, also nm
-A when the error message doesn't tell you which module caused the error.

Secondly, if you, like me, happen to have uClibc's feature of disallowing shared
libraries compiled without -fPIC turned on, then you'll find that Mesa related
stuff, like the 3D driver foo_dri.so won't load, with an error similar to
"libfoo.so wants to modify its text segment, please use -fPIC when compiling
shared libraries".  This is tough, because Mesa contains assembler code that
makes the code non-relocatable even if you add -fPIC to PICFLAGS in
configs/linux-dri-x86.  But you can find a patch on the net (google for
GLX_NO_TEXREL) that will change that.  You can then make everything Mesa-related
with CPPFLAGS=-DGLX_NO_TEXREL and it should take care of that.  Oh yes, and
GLX_USE_TLS is incompatible with relocatable Mesa.