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

Kevin Day thekevinday at gmail.com
Sun Aug 6 11:51:08 PDT 2006

On 8/5/06, Rupert Mazzucco <rmaz at gmx.net> wrote:
> > > > 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.
Sis & Via video drivers, I instead added:
#define	assert(expr)		((void) 0), but including assert.h would
probably be better

> 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.

Great advice; however, by the time this message made it to me, I had
fixed the source where applicable, found, and re-created that
GLX_NO_TEXREL patch you've found.

So I found the last notes you made somewhat funny in it's irony.

I am currently looking into the immediate next problem in which
anything linked against libGLU.so will segfault.

These are some of the notes I have already made to get xorg working
for me, but some may be hlfs/uClibc specific:

A Note to the above links: I had recently moved all of my mailing list
accounts to my new-gmail account and have been find problems with the
default settings of gmail.  As a result some messages get chopped,
vanish, or end on the lists a little late, but most of that is fixed
now.  You will also have to read past junk that I've typed to get to
whatever might be relevant to you.

I'll start trying your suggestions/fixes and see how they work.
Kevin Day

More information about the xorg mailing list