On 04/15/2016 10:22 AM, Ilia Mirkin wrote:
On Fri, Apr 15, 2016 at 12:18 PM, Chuck Atkins <chuck.atk...@kitware.com> wrote:
The problem this is trying to solve is that they both get installed and
create an ambiguous situation for which one get's used:
libGL.so -> libGL.so.1.5.0
libGL.so.1 -> libGL.so.1.6.0
libGL.so.1.5.0
libGL.so.1.6.0
FWIW this very issue has caused me to be stumped for at least a few
hours. Resolving it *somehow* would be fantastic. Note that only
letting one build at a time doesn't fully resolve the issue - some
clever enterprising individual will build it one way, install, then
build the other way, install. (Or forgetful individual...) And end up
with the same problem.
Of course it'd be *most* ideal if we could just have a single libGL
which did whatever we wanted it to when we wanted. But I'm guessing
there's a reason it was done this way.
There's quite a few factors.
1. I wrote the original "fake" GLX code around '94 before there was any
DRI. Before that, programs had to use the "XMesa" interface.
2. When DRI came along, libGL was based on SGI's GLX code. There was
some rudimentary support for switching to fake GLX when the X server
didn't support the GLX extension, but I think that got lost.
3. When we brought up gallium/softpipe we needed a fake GLX again, but
the existing one was tied to Mesa so we copied and pasted and hacked it
to work as a gallium state tracker.
Combining all these in one libGL would be quite a bit of work. There's
probably some technical challenges too, but limited resources is the
main factor.
-Brian
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
