<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Multiple conflicting libGL libraries installed"
href="https://bugs.freedesktop.org/show_bug.cgi?id=94086#c5">Comment # 5</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Multiple conflicting libGL libraries installed"
href="https://bugs.freedesktop.org/show_bug.cgi?id=94086">bug 94086</a>
from <span class="vcard"><a class="email" href="mailto:chuck.atkins@kitware.com" title="Chuck Atkins <chuck.atkins@kitware.com>"> <span class="fn">Chuck Atkins</span></a>
</span></b>
<pre>So, based on our discussion, I believe I've addressed this in the attached
patch now by adding an --enable-gallium-xlib-glx option to specify gallium or
classic xlib-glx implementation. I gave it this behavior instead of the osmesa
approach of --enable-xlib-glx and --enable-gallium-xlib-glx being competing
options in order to stay consistent with how the other GLX options work; i.e.
--enable-foo turns on foo with default bar1 implementation and
--enable-bar2-foo changes the implementation to bar2. Invalid configurations
for enabling the gallium-xlib-glx implementation will produce configure errors
but there is no conflicting way to specify both classic and gallium xlib-glx
implementations.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>