[Bug 217016] graphics/libGL: update to 17.0.1 to get llvm40 support

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Thu Mar 9 20:28:37 UTC 2017


Matthew Rezny <rezny at freebsd.org> changed:

           What    |Removed                     |Added
                 CC|                            |rezny at freebsd.org

--- Comment #8 from Matthew Rezny <rezny at 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.

More information about the freebsd-x11 mailing list