Since the same-dispatch-offset-different-glx-opcodes functions are defined in GLX, glXGetProcAddress should be a better place to handle them specially than _glapi_get_proc_address is. With that change, I am quite happy with the current status of shared glapi
http://cgit.freedesktop.org/~olv/mesa/log/?h=shared-glapi-2 >From a user's point of view, this branch brings two changes (implemented by the last two commits respectively). First, OpenGL ES 1.1 and 2.0 interop is fixed. There is now libglapi that is installed and shared by libGLESv1_CM and libGLESv2. The new libglapi has a stable API/ABI as described by glapi.h. The stability is to allow DRI drivers to be loaded as before. No external user of libglapi is expected. Then there is a new configure option, --enable-shared-glapi, which says that libGL should use the shared libglapi instead of defining its own copy. When enabled, it fixes OpenGL and OpenGL ES interop. This option is by default disabled as it is not needed for systems without OpenGL ES. When disabled, libGL is exactly the same as before. >From a packager's point of view, libGLESv1_CM and libGLESv2 should be considered wrappers of libglapi. They must be created from the same source tree as libglapi is. The reason for this is that the dispatch offsets are re-assigned whenever GLAPI XMLs are changed. Similarly, when --enable-shared-glapi is specified, libGL is also considered a wrapper of libglapi. I would hope that --enable-shared-glapi is enabled everywhere and is eventually removed. But before that happens, it may be desirable to have libGL export no more than OpenGL 1.2 plus GL_ARB_multitexture functions. These are the functions defined by OpenGL ABI for Linux and that have fixed dispatch offsets. With that, libGL and libglapi need not have to be from the same source tree. -- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
