Bug 81785

Summary: MESA checks on configure for llvm 3.4.2 and fails to build with 3.4.2 being installed
Product: Mesa Reporter: darkvision
Component: Mesa coreAssignee: mesa-dev
Status: RESOLVED INVALID QA Contact:
Severity: major    
Priority: medium CC: ahartmetz
Version: git   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description darkvision 2014-07-26 16:02:11 UTC
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
Comment 1 Tobias Klausmann 2014-07-26 16:57:09 UTC
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 :)
Comment 2 darkvision 2014-07-26 17:30:38 UTC
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...
Comment 3 Emil Velikov 2014-07-26 17:50:30 UTC
(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 :)
Comment 4 Tobias Klausmann 2014-07-26 18:19:23 UTC
(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.
Comment 5 darkvision 2014-07-27 03:49:33 UTC
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.
Comment 6 Marek Olšák 2014-07-27 10:49:35 UTC
LLVM's configure isn't very good either. It ignores --libdir.
Comment 7 darkvision 2014-07-27 12:09:10 UTC
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.
Comment 8 Jan Vesely 2014-07-27 16:38:36 UTC
(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
Comment 9 Marek Olšák 2014-07-27 17:31:20 UTC
(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?
Comment 10 darkvision 2014-07-27 20:59:10 UTC
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).
Comment 11 Emil Velikov 2014-09-22 19:14:51 UTC
*** Bug 70766 has been marked as a duplicate of this bug. ***
Comment 12 Timothy Arceri 2019-05-06 06:54:07 UTC
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.