2010/2/8 Kristian Høgsberg <k...@bitplanet.net>: > 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 did not realise that --whole-archive is not portable. Gallium's libGL.so plays the trick by defining a dummy function that calls glXGetProcAddress, which hopefully references all public symbols. It is no better though. >> 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. Sorry I was not clear. This patch series is the first smaller step.
Eventually, it might be desirable to be able to build most components in Mesa in a debug build, including multiple versions of libGL.so. It happens sometimes (weekly?) that some commits break the build of certain components. It should be good if we can suggest a set of configure options that may be used when working on structure/header changes. >>> 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 It may be a little confusing to enter a directory full of sources and build a shared library consisting of none of them. Maybe glx sources can go into src/gl/glx/? This is a minor issue that may be left for future. > possible to plug in different glx implementations, we already have the > dri sw driver as well as server side sw fallback for glx. It does not target packagers or end users. I was thinking how do we test a change to core Mesa in both libmesa.a and libmesagallium.a? There are another set of DRI drivers and libGL that live in src/gallium/. -- o...@lunarg.com ------------------------------------------------------------------------------ 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
