(In reply to comment #1)
> Is there a way or a parameter to disable building that driver [vmwgfx]?

--disable-gallium-svga

(In reply to comment #1)
> (In reply to comment #1)
> > Is there a way or a parameter to disable building that driver [vmwgfx]?
> 
> --disable-gallium-svga

Yes, of course. The kind of thing you have under your nose that you don't see. However, that doesn't fix the real problem behind, it just allows to build mesa with a subset of what can be built. I searched a bit and it seems others have problem building using the --enable-32-bit.

Still there with latest git version. The error message output by the build process is the following:

make[4]: Entering directory `/home/dema1701/projects/mesa/mesa/src/gallium/drivers/llvmpipe'
g++  -L/usr/lib/llvm-2.8/lib  -lpthread -lffi -ldl -lm  lp_test_format.o lp_test_main.o -o lp_test_format -Wl,--start-group  -L../../auxiliary/ -lgallium libllvmpipe.a -lLLVMpic16passes -lLLVMMCDisassembler -lLLVMXCoreCodeGen -lLLVMXCoreAsmPrinter -lLLVMXCoreInfo -lLLVMSystemZCodeGen -lLLVMSystemZAsmPrinter -lLLVMSystemZInfo -lLLVMSparcCodeGen -lLLVMSparcAsmPrinter -lLLVMSparcInfo -lLLVMPowerPCCodeGen -lLLVMPowerPCAsmPrinter -lLLVMPowerPCInfo -lLLVMPIC16AsmPrinter -lLLVMPIC16CodeGen -lLLVMPIC16Info -lLLVMMipsAsmPrinter -lLLVMMipsCodeGen -lLLVMMipsInfo -lLLVMMSP430CodeGen -lLLVMMSP430AsmPrinter -lLLVMMSP430Info -lLLVMMBlazeAsmPrinter -lLLVMMBlazeCodeGen -lLLVMMBlazeInfo -lLLVMLinker -lLLVMipo -lLLVMInterpreter -lLLVMInstrumentation -lLLVMJIT -lLLVMExecutionEngine -lLLVMCppBackend -lLLVMCppBackendInfo -lLLVMCellSPUCodeGen -lLLVMCellSPUAsmPrinter -lLLVMCellSPUInfo -lLLVMCBackend -lLLVMCBackendInfo -lLLVMBlackfinCodeGen -lLLVMBlackfinAsmPrinter -lLLVMBlackfinInfo -lLLVMBitWriter -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMX86AsmPrinter -lLLVMX86Info -lLLVMAsmParser -lLLVMARMDisassembler -lLLVMARMAsmParser -lLLVMARMCodeGen -lLLVMARMAsmPrinter -lLLVMARMInfo -lLLVMArchive -lLLVMBitReader -lLLVMAlphaCodeGen -lLLVMSelectionDAG -lLLVMAlphaAsmPrinter -lLLVMAsmPrinter -lLLVMMCParser -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMCore -lLLVMAlphaInfo -lLLVMSupport -lLLVMSystem -L/usr/lib/llvm-2.8/lib -lstdc++  -L/usr/lib/x86_64-linux-gnu -lXext -lXdamage -lXfixes -lXxf86vm -lX11-xcb -lX11 -lxcb-glx -lxcb   -L/lib/x86_64-linux-gnu -ldrm   -lm -lpthread -ldl -Wl,--end-group
/usr/bin/ld: skipping incompatible ../../auxiliary//libgallium.a when searching for -lgallium
/usr/bin/ld: cannot find -lgallium
collect2: ld returned 1 exit status
make[4]: *** [lp_test_format] Error 1
make[4]: Leaving directory `/home/dema1701/projects/mesa/mesa/src/gallium/drivers/llvmpipe'


No other drivers have this problem. I use the following to configure the build:
./autogen.sh --prefix=/usr --enable-shared-dricore --enable-gles1 --enable-gles2 --enable-openvg --enable-gl-osmesa --enable-xcb --enable-glx-tls --with-dri-drivers= --enable-gallium-egl --enable-gallium-llvm --enable-gallium-svga --disable-gallium-i915 --disable-gallium-i965 --disable-gallium-r300 --enable-gallium-r600 --disable-gallium-nouveau --enable-gallium-swrast --enable-texture-float --with-state-trackers=d3d1x,dri,egl,glx,vega,xorg  --enable-32-bit --libdir=/usr/lib/i386-linux-gnu --includedir=/usr/include/i386-linux-gnu

The problem is still present. Could it be a missing dependency (or not the good one) when using --enable-32-bit without disabling the llvmpipe driver? It will be a problem at some point now that r300g forces to compile llvmpipe.

Do you have 32bit build of LLVM installed? I don't think distros ship the 32bit llvm binaries, let alone development packages...  So you'll probably need to build a 32bit version of LLVM (not an easy task).

If you provide a 32bit version of LLVM (and add it to the PATH) then it --enable-32-bit will surely work.  But honestly this is brittle.

From my experience, the most reliable way of building 32bit versions of software is to use a 32bit chroot.  There are several tools that help creating and using a 32bit chroot from scratch for all distros.   Using -m32 only works for simple software with very few dependencies.

At any rate, this is an issue with the build environment, not the build scripts themselves, so there's nothing we can do about it, other than perhaps a warning message saying that LLVM + --enable-32-bit will obviously require a 32bit version of the LLVM development libraries installed.

It makes sense. The warning would really be a must I think. I'll just try to confirm it's the problem and we'll go from there.

Little question bugging me: are the --enable-64-bit and --enable-32-bit flags useless or broken? I mean, if I go with the 32 bit chroot solution, isn't it obvious that I'm building in a 32 bit environment and the flag can be ignored? I'm not very familiar with chroot, so I may be mistaken. Of course, the flags can still be used when not building the problematic drivers.

(In reply to comment #6)
> Little question bugging me: are the --enable-64-bit and --enable-32-bit flags
> useless or broken? 

They are not broken per se, but they do become useless once we start depending on a bit more esoteric libraries (such as LLVM), because all 64bit distributions till date only ship very few 32bit libraries (libc, zlib, x11, and that's about it).

> I mean, if I go with the 32 bit chroot solution, isn't it
> obvious that I'm building in a 32 bit environment and the flag can be ignored?
> I'm not very familiar with chroot, so I may be mistaken. Of course, the flags
> can still be used when not building the problematic drivers.

Yes, on a chroot these flags are pointless.