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... _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
