diff --git a/configure.ac b/configure.ac index 0e03af7..6400638 100644 --- a/configure.ac +++ b/configure.ac @@ -1762,14 +1762,25 @@ if test "x$enable_gallium_llvm" = xauto; then esac fi if test "x$enable_gallium_llvm" = xyes; then - AC_PATH_PROG([LLVM_CONFIG], [llvm-config], [no]) + if test "x$enable_32bit" = xyes; then + AC_PATH_PROG([LLVM_CONFIG], [llvm-config-32], [no]) + LLVM_LDFLAGS_ADD="-m32" + fi + if test "x$enable_64" = xyes; then + AC_PATH_PROG([LLVM_CONFIG], [llvm-config-64], [no]) + LLVM_LDFLAGS_ADD="-m64" + fi + if test "x$LLVM_CONFIG" = x; then + AC_PATH_PROG([LLVM_CONFIG], [llvm-config], [no]) + fi if test "x$LLVM_CONFIG" != xno; then LLVM_VERSION=`$LLVM_CONFIG --version | sed 's/svn.*//g'` - LLVM_CFLAGS=`$LLVM_CONFIG --cppflags|sed -e 's/-DNDEBUG\>//g' -e 's/-ped + LLVM_CFLAGS=`$LLVM_CONFIG --cxxflags|sed -e 's/-DNDEBUG\>//g' -e 's/-ped LLVM_LIBS="`$LLVM_CONFIG --libs engine bitwriter`" LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags` + LLVM_LDFLAGS="$LLVM_LDFLAGS $LLVM_LDFLAGS_ADD" DEFINES="$DEFINES -D__STDC_CONSTANT_MACROS" MESA_LLVM=1 else
Created attachment 56473 [details] [review] Improved version of the patch that touches mklib as well I found that mesa would not compile after doing a make distclean, due to my previous patch. I determined that it was due to mklib erroring on the -m32 I was adding when compiling xorg-r600. So I modified mklib to output a warning and skip the the next argument in this case rather than exiting. By applying this patch to git head (f09910f399d747e524731953bb11b64c1f4821d0). I can use the following command to build mesa in 32bit on a 64bit (Fedora) system. Which covers a large portion of mesa CFLAGS='-m32' CXXFLAGS='-m32' ./autogen.sh --prefix=/usr --libdir=/usr/lib --with-dri-drivers="" --with-gallium-drivers=r600,swrast --enable-gallium-egl --enable-openvg --enable-gles1 --enable-gles2 --enable-texture-float --enable-vdpau --enable-xvmc --enable-osmesa --enable-xorg --enable-texture-float --enable-32-bit
This patch doesn't apply correctly on latest git. However, when fixed, it helps. I don't know if it's the same situation everywhere, but under ArchLinux, llvm-config-32 should be replaced by llvm-config32 (probably the same thing should be done for llvm-config-64, but I can't test it, my setup has llvm-config). Also, I think we shouldn't use LLVM_LDFLAGS_ADD with the current git code.
Comment on attachment 56473 [details] [review] Improved version of the patch that touches mklib as well Review of attachment 56473 [details] [review]: ----------------------------------------------------------------- ::: configure.ac @@ +1776,1 @@ > Since this bug as been reopened. I may be wrong here, but according to the following patch (http://cgit.freedesktop.org/beignet/commit/?id=25bfb6ca3b22fc8f439ebd58ee03e33bfceeb927), using llvm-config-32 is not the same as llvm-config32. The former points to llvm-config version 3.2 on some distributions (or it could be on concurrent llvm installations), while the second points to a 32bit version of llvm-config. However, on other distributions, I've seen the form you are proposing being used to identify 32 and 64bit versions.
Every distribution uses its own hacks to do multilib, and I don't think anything related to this really belongs in mesa. Even if you can find a sane defaults that don't result in really bad results in some distros, you are putting amd64-specific magic in package that supposedly can be used on any arch. For a cleaner solution, take a look at bug #73100. It uses well-established practice and works for multilib, assuming you pass proper --host to configure and split llvm-config accordingly.
(In reply to comment #4) > Every distribution uses its own hacks to do multilib, and I don't think > anything related to this really belongs in mesa. Even if you can find a sane > defaults that don't result in really bad results in some distros, you are > putting amd64-specific magic in package that supposedly can be used on any > arch. > > For a cleaner solution, take a look at bug #73100. It uses well-established > practice and works for multilib, assuming you pass proper --host to > configure and split llvm-config accordingly. Then everything that has to do with cross-compiling should be stripped off mesa. I'm pointing the infamous "--enable-XXbit" flags here. I've been using --host for a long time to circumvent limitations/problems encountered with the --enable-XXbit flags (but you have to set some other variables to have a proper build). We should seriously consider taking a decision about cleaning the --enable-XXbit flags off. Either we fix it properly (which doesn't seem to be happening even with the many patches laying around) or we strip it completely and we let the builder set the proper environment variables to do the job.
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.