> This is really not an option at all. It will break pretty much
> everything. Let's assume your libGL.so has not implemented
> EXT_paletted_texture. In this case, glColorTableEXT() is not available
> at linktime. Asume an application now uses code like this (which is
> common practice):
[snip]
I completely understand the issue. I also understand that Mesa (and
hopefully your implementation) will continue to export the entry points
which you previously exported. Therefore an app which doesn't port to the
new ABI will continue to function with both of these implementations. To
assert that "it will break pretty much everything" is a bit overstated IMO.
> It will simply break at linktime, or depending upon ld.so relevant
> flags at runtime. Why ? Because glext.h MUST define
> EXT_paletted_texture to state that the relevant defines are there. So
> what this option does it to force every application to use
> glXGetProcAddressARB() for every extension function since it cannot
> tell whether the direct callable function will be present. This will
> lead to something like this:
>
> #ifdef GL_EXT_paletted_texture
> #ifdef GL_ARB_get_proc_address
> (*glXGetProcAddressARB("glColorTableEXT")(...);
> #else
> glColorTableEXT(...);
> #endif
> #endif
This is the requirement of the current ABI, and is orthogonal to whether or
not glext.h is included automatically. If you don't want to be
ABI-compliant, do nothing and your code will continue to work in a
non-portable manner. If you want to use the new ABI, you must write code
like the above anyway. The only exception is new extensions which were
previously not advertised, and you can avoid those in my proposal by adding
a define to your makefile e.g. __GL_DO_NOT_INCLUDE_GLEXT_H.
> This means that portablity to other OSes is only at the expense of a
> significant rewrite of code. In fact, by default all current
> applications that use extensions will break. Unless of course libGL.so
> includes every possible extension function entry point at linktime.
I think there is a disconnect somewhere... this is well understood to be the
objection you and Steve are making and has been rehashed several times over
the last few days. It has also been stated that Mesa and hopefully your own
implementation will continue to export symbols that apps were already
depending on. As I mentioned in my follow up post, our exposure here is
reduced by these measures, and the workaround is very simple, a single token
in a makefile to allow the app to compile/link without the "pollution" of
glext.h.
> > 2) add a symbol, any symbol, which promises that glext.h exists
> > Pros:
> > - apps that want extensions on Linux can reliably include
> this header
> > - new code is portable to other OS's
> > Cons:
> > - apps that want extensions on Linux must include this header
> > - the problem of whether or not to include glext.h on
> other platforms
> > remains unsolved
>
> Yes and no. Back again to the fact that glext.h makes only sence if
> you either are running on Windows (as you then have
> wglGetProcAddress()), or if GLX_ARB_get_proc_address is defined.
> So simply assuming that "#if defined(WINDOWS) ||
> defined(GLX_ARB_get_proc_address)"
> will tell the availability of glext.h is not working.
In an ideal world it would not be necessary in Windows. As has oft been
argued on this very list, lets not let the mistakes of Windows dictate our
actions. Lets leave the application requirement of glext.h as a
windows-only thing, for which it was originally intended, and hide linux
users from the same pain.
