[Mesa-dev] [PATCH] glx: Refactor the configure options for glx implementation choice

[Brian Paul]

On 04/15/2016 10:22 AM, Ilia Mirkin wrote:
> On Fri, Apr 15, 2016 at 12:18 PM, Chuck Atkins <chuck.atkins at 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