[Mesa-dev] Understanding GLX_INDIRECT_RENDERING (libOSMesa fails to link due to gl_dispatch_stub*)
dbn.lists at gmail.com
Tue Jun 7 12:06:38 PDT 2011
On Tue, Jun 7, 2011 at 11:13 AM, Brian Paul <brianp at vmware.com> wrote:
> On 06/07/2011 11:26 AM, Jeremy Huddleston wrote:
>> On Jun 7, 2011, at 1:01 PM, Jeremy Huddleston wrote:
>>> On Jun 7, 2011, at 12:01 PM, Jeremy Huddleston wrote:
>>>> So what is the proper fix here? How should libOSMesa be getting built?
>>>> Should libmesa.a be providing those stubs (rather than my change which
>>>> put them in mesa/osmesa)? Should the stubs be getting exported by libGL?
>>>> Should GetHistogramEXT be exported by libGL?
>>>> Based on my understanding, it seems like we should bring these stubs
>>>> into libmesa.a (and remove them from mesa/xlib). Does that sound right?
>>> Actually... I'm perplexed about another issue here... why is libOSMesa
>>> linking against both libglapi and libGL?
>>> It seems like the only things resolving into libGL are the stub symbols
>>> missing in libglapi. If we provide them in osmesa, why does libOSMesa need
>>> to link against libGL at all?
>>> Similarly, libOSMesa seems to build fine if I just don't include
>>> libglapi.a and let it resolve those calls into libGL (which it can re-export
>>> to provide the gl* entry points). This of course requires libGL to be
>>> glapi-aware (which glx/apple isn't yet).
>>> As is, including libglapi.a in libOSMesa and in libGL will result in two
>>> copies of libglapi existing in memory which seems like a recipe for disaster
>>> since there will be two different dispatch tables, etc. Perhaps this isn't
>>> a problem on systems with flat namespaces, but on darwin, it is.
>> Ok, I see what is happening. configs/darwin bitrotted and included the
>> -lGL, but other configs have since removed that. It looks like I should
>> just remove -lGL from OSMESA_LIB_DEPS in addition to the other changes that
>> I've already sent for osmesa.c
>> It looks like -lGL is still done in default, beos, and aix ... so someone
>> might want to update those as well...
> At one time, I had things set up so that one libGL.so contained both the GLX
> and OSMesa interfaces. An app could create a context of each time and
> freely switch between them with glX/OSMesa-MakeCurrent(). A while back this
> got changed so the OSMesa stuff lives in its own libOSMesa.so library.
IIRC, it became really complicated with hidden symbol visibility to
keep all the setups linking correctly. I'm sure there's a way to fix
it, but it could be hairy.
More information about the mesa-dev