On Wed, Jun 8, 2011 at 3:08 AM, Jeremy Huddleston <jerem...@apple.com> wrote: > > On Jun 7, 2011, at 2:13 PM, Brian Paul wrote: > >>> 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. >> >> At first glance, I'd suggest just omitting all the OSMesa stuff on Darwin >> for now. > > Ok, well after omitting -lGL from OSMESA_LIB_DEPS and including the stubs in > osmesa.c (patch on mesa-dev for review), things seem to be working well. > > Is that patch the correct fix? Has libOSMesa been failing to build correctly > on other architectures as well? If not, how is it resolving those symbols > (or do architectures usually build libOSMesa without GLX_INDIRECT_RENDERING)? The patch looks good to me. > I'm confused about how to interpret the matrix of GLX_INDIRECT_RENDERING and > GLX_DIRECT_RENDERING: GLX_DIRECT_RENDERING: src/glx supports direct rendering GLX_INDIRECT_RENDERING: adapt libglapi for src/glx
src/glx always supports indirect rendering. When GLX_INDIRECT_RENDERING is not defined, it either won't build or will use wrong opcodes for certain functions (glGenTexturesEXT and etc). Because GLX_INDIRECT_RENDERING adapts libglapi, you are not supposed to build other libraries that use libglapi when the macro is defined... unless changes similar the patch you posted are applied to them. > -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING > > ^^ libGL supports both direct and indirect rendering src/glx/ supports both direct and indirect rendering > -DGLX_INDIRECT_RENDERING -UGLX_DIRECT_RENDERING > ^^ libGL supports only indirect rendering (?) src/glx supports only indirect rendering > -UGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING > ^^ libGL supports only direct rendering (?) ... This doesn't seem to be the > case since the indirect-foo is always included in src/glx/*.[hc] src/glx won't build; if it does, it supports both direct and indirect rendering. Indirect rendering will send wrong opcodes for certain functions. > -UGLX_INDIRECT_RENDERING -UGLX_DIRECT_RENDERING > ^^ not supported? src/glx won't build; if it does, it supports only indirect rendering, with the same issue above > > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > -- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev