2010/2/6 Chia-I Wu <olva...@gmail.com>: > On Fri, Feb 05, 2010 at 07:24:00PM -0500, Kristian Høgsberg wrote: >> These two patches move things around in GLX a bit. To make it possible >> to use libGL with EGL on framebuffer without pulling in X dependencies >> this patch make the GLX entry points and all the indirect API a >> ./configure time option. When disabled, libGL is essentially just glapi >> and needs libEGL to be useful. I had to go back to using a list of >> glapi object files instead of libglapi.a, since without the glx functions >> nothing is left to pull in the glapi files. > Do we have to list the glapi object files? Is -Wl,--whole-archive > enough?
I don't think that works on other platforms. > I think something like "ABI breakage for Linux/X11" should also be added > to the description of --disable-glx. libGL.so is required to have both > GL and GLX entries on Linux/X11. Incidentally, there is an implementers > guide on Khronos website that you might find interesting Is that really necessary? The option defaults to off, and anybody passing --disable-glx shouldn't be surprised when glx symbols are not no longer present in libGL. It's pretty self-explanatory. > I've also been thinking how to design the configure options such that it > is possible to produce libraries for the target platform (libGL with or > without GLX, or maybe OpenGL ES DRI drivers) for normal users. > Addtionally, it should also be possible to enable everything so that any > build failure can be catched. We might be able to start with smaller > steps. What smaller step would you suggest? I don't see a way to break this patch into smaller pieces, and it's functionality we'll have to add to mesa at some point. >> The other patch renames glx to gl, now that it's no longer glx only, and >> moves the code up one level from src/glx/x11 to src/gl. The patch >> drops src/glx/mini; it's DRI1 only, not maintained and EGL on KMS is a >> better solution for the use cases where miniglx was useful. > I haven't tried this. But ideally, I think src/glx/x11/ can be moved up > one level to src/glx/. This directory will not be visited when > --disable-glx. But when visited, it will build libglx.a from the > sources. > > We can then build libGL.so with or without libglx.a depending on the > configure optins. Later, src/mesa/drivers/x11/ could be changed to > build libglxsw.a. We will be able to choose between 3 flavors of > libGL.so, or choose all of them (to catch build failure) I wanted to do something similar, but the problem is: where do you build libGL? And glx is part of libGL so it's consistent to call the directory src/gl. And I don't think it's worth the effort to make it possible to plug in different glx implementations, we already have the dri sw driver as well as server side sw fallback for glx. cheers, Kristian ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
