This is the configure line I use with master for 32-bit binaries, and it works: ./configure --prefix=/opt/xorg --libdir=/opt/xorg/lib32 --with-dri-drivers=r600,swrast --disable-gallium --with-dri-driverdir=/opt/xorg/lib32/dri --enable-glx-tls PKG_CONFIG_PATH=/opt/xorg/lib32/pkgconfig/ --enable-32-bit CFLAGS="-march=native -O2 -g" Same line with glsl2 branch fails: /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../libtalloc.so when searching for -ltalloc I obviously don't have talloc installed as 32-bit, but Mesa's configure thinks I do (I have the 64-bit talloc installed): configure:5614: checking for TALLOC configure:5621: $PKG_CONFIG --exists --print-errors "talloc" configure:5624: $? = 0 configure:5637: $PKG_CONFIG --exists --print-errors "talloc" configure:5640: $? = 0 configure:5697: result: yes I think it should try to link with talloc to make sure the right talloc is there.
Try 2. Build 32-bit talloc: ./configure --prefix=/opt/xorg --libdir=/opt/xorg/lib32 CC=gcc -m32 CFLAGS=-march=native -O2 -g make make install Problem is that mesa calls pkg-config --libs from the Makefile and not from configure, at which time PKG_CONFIG_PATH is no longer set. Try 3. Export PKG_CONFIG_PATH. Now it worked. I suggest that pkg-config --libs be run at configure time, or just build the builtin talloc if system one can't be found (or wrong bitness).
I am experiencing a similar issue with the recent git master, most likely due to the GLSL branch merge: > mklib: Making Linux shared library: r600_dri.so.tmp > g++ -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XCB_DRI2 -DHAVE_LIBUDEV -DHAVE_XEXTPROTO_71 -DHAVE_LIBDRM_RADEON=1 -I/usr/include/libdrm -DFEATURE_GL=1 -o r600_dri.so.test ../../../../../src/mesa/drivers/dri/common/dri_test.o r600_dri.so.tmp -ldrm -lexpat -lm -lpthread -ldl -ldrm_radeon -ldrm > r600_dri.so.tmp: undefined reference to `talloc_strdup_append' > r600_dri.so.tmp: undefined reference to `talloc_asprintf' > r600_dri.so.tmp: undefined reference to `talloc_unlink' > r600_dri.so.tmp: undefined reference to `talloc_strndup' > r600_dri.so.tmp: undefined reference to `_talloc_free' > r600_dri.so.tmp: undefined reference to `_talloc_array' > r600_dri.so.tmp: undefined reference to `_talloc_reference_loc' > r600_dri.so.tmp: undefined reference to `talloc_parent' > r600_dri.so.tmp: undefined reference to `talloc_init' > r600_dri.so.tmp: undefined reference to `talloc_strdup' > r600_dri.so.tmp: undefined reference to `_talloc_zero' > r600_dri.so.tmp: undefined reference to `_talloc_steal_loc' > r600_dri.so.tmp: undefined reference to `_talloc_zero_array' > r600_dri.so.tmp: undefined reference to `talloc_asprintf_append' > r600_dri.so.tmp: undefined reference to `talloc_vasprintf_append' > r600_dri.so.tmp: undefined reference to `talloc_named_const' > r600_dri.so.tmp: undefined reference to `talloc_strndup_append' > r600_dri.so.tmp: undefined reference to `_talloc_set_destructor' > collect2: ld returned 1 exit status My configure flags include --enable-32-bit and --disable-64-bit.
Thanks for tracking down the issue. Hopefully this fixes it: commit 639cdd3782c40c422c33c907949376c735d9340c Author: Eric Anholt <eric@anholt.net> Date: Sun Aug 22 17:34:18 2010 -0700 mesa: AC_SUBST the talloc libs/cflags so the ./configure results are saved. I had used pkg-config from the Makefile because I didn't want to screw around with the non-autoconf build, but that doesn't work because the PKG_CONFIG_PATH or TALLOC_LIBS/TALLOC_CFLAGS that people set at configure time needs to be respected and may not be present at build time. Bug #29585
(In reply to comment #3) > Thanks for tracking down the issue. Hopefully this fixes it: Now on a clean Git clone the build succeeds. Thus I’d confirm this as fixed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.