Date: Thu, 09 Mar 2017 20:28:37 +0000 From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 217016] graphics/libGL: update to 17.0.1 to get llvm40 support Message-ID: <bug-217016-7141-wUVshLNbi6@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-217016-7141@https.bugs.freebsd.org/bugzilla/> References: <bug-217016-7141@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217016 Matthew Rezny <rezny@freebsd.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rezny@freebsd.org --- Comment #8 from Matthew Rezny <rezny@freebsd.org> --- Allowing more flexibility of the LLVM version to allow those who are ahead to use the one they currently have installed, i.e. llvm40 instead of llvm39 at the moment, is a good idea. Allowing use of older versions of LLVM is not such a good idea; the result will be degraded functionality, if it works at all. Support of newer OpenGL versions and newer hardware, i.e. amdgpu, requires fairly current LLVM. Just because Mesa could be built with 3.6 that does not mean it would be fully functional. Also, the LLVM port needs to provide a library for Mesa to use, but as it is not built by default it is not provided by all the llvm ports. llvm36 might provide the library, I haven't checked, it's ancient. llvm37 does provide the library the old way, meaning the shared LLVM lib is built and all the LLVM tools link to it. LLVM 3.8 introduced the option to build the shared library without linking anything to it, which is the recommended way as the static build of LLVM is more performant than a dynamic linked build. I experimented with both llvm38 and llvm39 ports some moths ago. llvm39 was patched to provide the necessary shared library which is now used by almost all OpenGL and OpenCL ports. llvm38 should be able to provide the shared library with the same changes, but the build failed on all my attempts, so I punted on it given that llvm39 was already available and working. The rather specific BUILD/RUN_DEPENDS on 3.9.0_4 is to ensure that the version of the llvm39 port in use provides the required shared library, prior port revisions did not. Therefore, we would need a version whitelist to safely allow use of older llvm ports. That would be be a good deal of unnecessary complication for little if any benefit, and that only addresses Mesa. For OpenCL there are a number of ports other than Mesa which have their own, narrower version requirements for LLVM, not all of which can be satisfied with a single version, but as seen after the last update there can be a problem with multiple LLVM versions installed (numerous people reported failures in Mesa when both llvm37 and llvm39 were present, cured by removing llvm37, probably related to the shared lib from llvm37 which had extra unnecessary consumers that may have caused it to get preloaded). Additionally, this all would go counter to the effort to clear old llvm ports of dependents. That said, a patch to require llvm39 but use llvm40 if it is already installed would be nice, but that is not what the proposed patch does. Instead, it merely allows MESA_LLVM_VER to be more easily overridden while also dropping the min version and bumping the default version, dropping part of post-patch, rolling the post-patch changes or a subset thereof into patch-configure and patch-configure.ac (which need not be patched), and there is some other change to configure patches I have no looked at close enough to see whether the make sense for the 13 -> 17 bump given the rest is incorrect. Mesa 17.0 will either simply require llvm40 or it will require llvm39 and accept llvm40. I have been testing 17.0 built with llvm39 so far while watching the LLVM 4.0 release get pushed back. Given 4.0 is not yet released and there are numerous other ports to consider, many of which just moved to llvm39 if not still stuck further behind, it is probably imprudent to rush to require llvm40 for Mesa 17.0. Mesa 17.1, which is at least a month away, will require llvm40. We can be sure llvm40 will be in good shape by then, other parts of the graphics stack that may not yet have caught up should be by then, and to not use LLVM 4.0 would forgo some of the benefit of upgrading Mesa to that point. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-217016-7141-wUVshLNbi6>