http://filebin.ca/21BLOQZgI8Xh/mesa.conf
http://filebin.ca/21BLZM5UsAmW/dmesg
http://filebin.ca/21BLfuazDXEf/Xorg.0.log

linux (radeon drm git), llvm git, xserver git, ati xorg drv git, mesa git

Please attach a backtrace of the crash, preferably from gdb.

I can't, segfault happens into a thread with a corrupted stack (gdb says)
But I get some "Mesa: User error: GL_INVALID_OPERATION in function(invalid call)"
in log, only when asm is on.
(I suspect strongly x86 assembly code in glapi, I'm going excise it and try again)

I did excise the glapi/mapi x86 assembly code. Working and no more
"Mesa: User error: GL_INVALID_OPERATION in function(invalid call)".
This is where bad things are happening.

This bug seems to be not related to my bug #90370 (radeon related), did you have a look at it?

It looks to me you are trying to do a 32bit build (?)

what is included in $steam_i686_gnu_target variable?

You should give following flags to make sure things go ok (see docs/autoconf.html):

"./configure CC="gcc -m32" CXX="g++ -m32" --build=x86_64-pc-linux-gnu --host=i686-pc-linux-gnu"

It's not a multilib build. It's a standard 32 bits build on x86_64 (CC="i686-pc-linux-gnu")

So you think the issue is the assembly code from the glapi dispatch table not
compiled properly?

(In reply to Sylvain BERTRAND from comment #6)
> It's not a multilib build. It's a standard 32 bits build on x86_64
> (CC="i686-pc-linux-gnu")
> 
> So you think the issue is the assembly code from the glapi dispatch table not
> compiled properly?

Yep, you'll need the arguments in comment #5 for your build. Otherwise CCASFLAGS wont have -m32.

I tried -m32. Did not change anything. -m32 and -m64 are only for a gcc
multilib toolchains. Here, it's a normal x86 toolchain, with i686-pc-gnu-gcc
calling i686-pc-gnu-as (I checked i686-pc-gnu-gcc verbose output).
Did you mean something is hardcoded in the build system for the availabily
of the -m32/-m64 flags? If yes, what is it?

Well, the asm tls path is working 'ok', with only a few "Mesa: User error: GL_INVALID_OPERATION in function(invalid call)".
It's the relevant code path anyway. Let's deal with this one for good.

(In reply to Sylvain BERTRAND from comment #8)
> I tried -m32. Did not change anything. -m32 and -m64 are only for a gcc
> multilib toolchains. Here, it's a normal x86 toolchain, with i686-pc-gnu-gcc
> calling i686-pc-gnu-as (I checked i686-pc-gnu-gcc verbose output).
> Did you mean something is hardcoded in the build system for the availabily
> of the -m32/-m64 flags? If yes, what is it?

Did you have also '--build=x86_64-pc-linux-gnu --host=i686-pc-linux-gnu'? It could be that '-m32' is not necessary here (I would not count on it though because I believe libtool needs it) but at least the build and host arguments are *very* necessary because libtool makes decisions based on them. So when you feed these to autogen.sh, it should generate you proper libtool file contents.