I have LLVM 3.4.2 installed but mesa-git/configure fails to build and requests llvm >= 3.4.2 to be installed. configure seem to check for LLVM_VERSION_PATCH in llvm/Config/config.h but that isn't defined and therefore LLVM_VERSION_PATCH is set to "0". The LLVM_REQUIRED_VERSION_PATCH is set to "2" and thus the compare of LLVM_VERSION_PATCH=0 vs.LLVM_REQUIRED_VERSION_PATCH=2 will fail. This is the code that failes: if ac_fn_c_compute_int "$LINENO" "LLVM_VERSION_PATCH" "LLVM_VERSION_PATCH" "#include \"${LLVM_INCLUDEDIR}/llvm/Config/config.h\""; then : else LLVM_VERSION_PATCH=0 fi and radeon_llvm_check() { if test "x$enable_gallium_llvm" != "xyes"; then as_fn_error $? "--enable-gallium-llvm is required when building $1" "$LINENO" 5 fi LLVM_REQUIRED_VERSION_MAJOR="3" LLVM_REQUIRED_VERSION_MINOR="4" LLVM_REQUIRED_VERSION_PATCH="2" if test "${LLVM_VERSION_INT}${LLVM_VERSION_PATCH}" -lt "${LLVM_REQUIRED_VERSION_MAJOR}0${LLVM_REQUIRED_VERSION_MINOR}${LLVM_REQUIRED_VERSION_PATCH}"; then as_fn_error $? "LLVM $LLVM_REQUIRED_VERSION_MAJOR.$LLVM_REQUIRED_VERSION_MINOR.$LLVM_REQUIRED_VERSION_PATCH or newer is required for $1" "$LINENO" 5 fi
I had the exact same problem, but came to the conclusion that LLVM needs to be patched to resolve this. This was done for Opensuse and works fine! https://build.opensuse.org/package/view_file/home:tobijk:X11:XOrg/llvm/cmake-patchversion.patch?expand=1 go bother the LLVM package maintainer :)
According to the llvm announcement for 3.4.2 it is API compatible with 3.4. MESA checks for the API (which is 3.4) and not for the version (which is 3.4.2). Yes, patching LLVM works as does patching MESA to not check for the patch version. Take it as a note... i can temp fix it to continue testing...
(In reply to comment #1) > I had the exact same problem, but came to the conclusion that LLVM needs to > be patched to resolve this. This was done for Opensuse and works fine! > > https://build.opensuse.org/package/view_file/home:tobijk:X11:XOrg/llvm/cmake- > patchversion.patch?expand=1 > > go bother the LLVM package maintainer :) It seems like building llvm with cmake is not the most common practise - iirc there was an RTTI issue a while back and now this thus. Might be better if you forward the patch to the llvm if you haven't already. This way more people can benefit from your work(patch) :) (In reply to comment #2) > According to the llvm announcement for 3.4.2 it is API compatible with 3.4. > MESA checks for the API (which is 3.4) and not for the version (which is > 3.4.2). > > Yes, patching LLVM works as does patching MESA to not check for the patch > version. > > Take it as a note... i can temp fix it to continue testing... I believe the main issue with dropping that patch version check in mesa is that mesa (some of the radeon code actually) depends on functionality that did not exist in earlier versions - including 3.4.0 and 3.4.1. Perhaps the configure.ac check is not perfect but as llvm provides a more robust method of detection we might incorporate that in mesa :)
(In reply to comment #3) > (In reply to comment #1) > > I had the exact same problem, but came to the conclusion that LLVM needs to > > be patched to resolve this. This was done for Opensuse and works fine! > > > > https://build.opensuse.org/package/view_file/home:tobijk:X11:XOrg/llvm/cmake- > > patchversion.patch?expand=1 > > > > go bother the LLVM package maintainer :) > > It seems like building llvm with cmake is not the most common practise - > iirc there was an RTTI issue a while back and now this thus. Might be better > if you forward the patch to the llvm if you haven't already. This way more > people can benefit from your work(patch) :) > There was a intention in switching to cmake a while back, i think it was easier to build the radeonsi (?) backend with it. I'll ask the patchcreator to upstream it.
There is at least one more difference in a cmake build of llvm compared to a configure build which will cause mesa fail to compile (missing symbols): If you are using shared libraries in llvm you should better use configure or MESA will not be happy :-) Since the configure build of llvm will add the missing patch version to config.h this is not a mesa bug. I'll change the status to INVALID.
LLVM's configure isn't very good either. It ignores --libdir.
Yes... you need to patch a few libdir locations but at least MESA compiles fine with configure/LLVM while i spent a whole day to compile MESA with cmake/LLVM just to finally give up on using cmake.
(In reply to comment #7) > Yes... you need to patch a few libdir locations but at least MESA compiles > fine with configure/LLVM while i spent a whole day to compile MESA with > cmake/LLVM just to finally give up on using cmake. llvm cmake by default compiles with -fno-rtti (see r213663, r213664). However, llvm-config fails to export the setting due to [0] unless [1] is applied. I have no problems building mesa with cmake LLVM with the mentioned patch. Alternatively you can try building LLVM with RTTI enabled. (never tested that myself) [0] http://llvm.org/bugs/show_bug.cgi?id=14200 [1] http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131230/200267.html
(In reply to comment #7) > Yes... you need to patch a few libdir locations but at least MESA compiles > fine with configure/LLVM while i spent a whole day to compile MESA with > cmake/LLVM just to finally give up on using cmake. Which libdir locations do I need to patch? Where can I find them?
I was using llvm cmake until MESA 10.2 and had no problems with REQUIRES_RTTI=1, worked very well. The only module that failed after upgrading from 10.0.x to 10.2.x was xa, which complains about missing def like llvm::format_object_base. When using latest MESA git another miss was llvm::JITMemoryManager. I tried --disable-xa and everything was OK. After switching to configure MESA 10.2.4 builds fine, even with xa enabled. In reply to comment #9: I'm compiling on Slackware linux. -current has LLVM 3.4.2 and MESA 10.2.4 in the tree (sources in subdir d and x). The slackbuild script for LLVM uses configure. The libdir locations can be found there. You also need a patch for removing rpath data if you take care about that (works better on the cmake build).
*** Bug 70766 has been marked as a duplicate of this bug. ***
Autotools build scripts have been removed. Please open a new bug if there is a problem with Meson
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.