On Wed, 22 Mar 2000, Michael Gold wrote:
> > All future Linux/OpenGL/Mesa development should use
> > glXGetProcAddressARB.
> > But in the mean time, these three items will help ensure backward
> > compatibility with the existing applications, both at compile
> > and runtime.
>
> From your description then it sounds like the scenario Steve describes is
> not (or less) likely to be a problem in practice. If the prototypes are
> defined, there will be no compile errors, and if the EXT entry points exist
> in the dso, there should not be link problems either. Do you agree?
No. Mesa is only one of the OpenGL implementations for Linux - there
are others. Will there be similar entrypoints in the nVidia/SGI OpenGL?
How about XiG's implementation?
This is a spec for a standard - and if adding all those entrypoints
into every libGL.so (and updating them regularly) is to be a part of
the specification - then we need to write it in.
I strongly suspect there will be objections from all those people
who now have a new maintenance task on their list.
> > Not doing this would result in a support nightmare of which the very
> > thought sends a shiver down my spine.
>
> This is good news Brian, it sounds like you have anticipated the
> compatibility issues very well.
>
> Steve, does this address your concerns?
Well, only if we write into the spec that conformant implementations
have to have all the extension entry points inserted as stubs into
every libGL.so - so long as (say) nVidia don't do that, there is
still a major problem.
I don't think that's going to be a very popular move.
The whole idea of all this glGetProcAddress stuff was precisely
to avoid doing that.
In any case, it sucks as a solution because we just *know* that
libGL.so will lag behind glext.h - so you end up with the kind
of horrible mess where some existing applications will work
(because they only use extensions that are in both glext.h
AND libGL.so) and others won't (because they use extensions
from glext.h that have not yet made it into libGL.so). If
you slow down delivery of glext.h changes so that they
mirror the latest libGL.so's then you lose much of the benefits
of using glext.h.
The spec should also say what happens if you (illegally) call
one of those stubs - perhaps it should be a GL Error kind of
a thing - perhaps it should just silently do nothing - or
maybe we want to say it's "undefined" (ie you get a core
dump). I don't care which we say - but if we do go this
way, we need to say something.
We keep talking about "legacy apps" in this context - and I'd
like to point out that it's NOT just older code that'll cause
a one-time hit that we can somehow overcome by judicious
placement of dummy routines into libGL.so
Note that ANY program ported from a non-oglbase system at
any time in the future could be vulnerable to this problem.
Since (currently) only Linux has an oglbase spec, there is
no guarantee that we won't have continuing problems in the
future as new programs (not yet written) for (say) Solaris
or IRIX are ported onto Linux/oglbase.
It's likely that some OpenGL implementations would support
oglbase even though they are not Linux (it's virtually
certain that BSD UNIX will - presumably SGI would do it
for IRIX) - but that doesn't guarantee that we eliminate
the problem - it's pretty unlikely that Microsoft would
ever adopt oglbase, so there will always be a steady
stream of OpenGL applications porting over from Windoze
to cause ongoing problems.
Anyway, if all Linux OpenGL's will commit to adding those
entrypoints into their libGL.so's by the time oglbase
becomes law - then I have a much smaller objection to
including glext.h into gl.h
Just out of interest, what's the objection to doing the
opposite and including gl.h into glext.h ? It seems to
me that this would be as good a solution as the reverse
from the point of saving our children from the terrible
evils of needing two headers - and yet preserve the
ability of existing legal OpenGL programs to work
unmolested.
If we did that, it might be preferable to think of a
better name (glbase.h?) - or even to define an entirely
new header file that says:
#include <GL/gl.h>
#include <GL/glext.h>
One final point. Brian tells me that the gl.h that
shipped with Xfree86 4.0.0 does not include glext.h
Since that version of 4.0.0/Mesa will ship with SuSE
6.4 in a few weeks, I'd say the issue was already
settled. Any program that tests for the existance
of glext.h and uses that to turn on all it's
glGetProcAddress stuff will have to #include glext.h
in order to run under SuSE 6.4.
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: [EMAIL PROTECTED] http://www.hti.com
Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1
