Jon wrote:
| "Linking" and "libraries" and all other implementation-dependent
| mechanism/SDK/runtime issues are *not addressed* and *should not be
| addressed* by OpenGL at the specification level. Nothing except common
| practice causes GL and GLX functions to be placed in the same library,
| and nothing prohibits an implementation from, say, splitting
| functionality up into '-lGL -lGLext -lGLX -lGLXext -lGLU -lGLUext' - so
| the same runtime environment issues may occur while querying GLX or GL
| extensions. The specification must allow for this, which is another
| reason for having GetProcAddress return a detectable error IMO.
Well, I've spent about two hours trying to think this through.
Some observations:
1. Some functions might be statically linked, and the executable
might be stripped. If we want glXGetProcAddress("foo")==&foo,
and more importantly if we want to invoke the same function
when dereferencing a pointer returned by glXGetProcAddress as
when calling the function by name, then the implementation is
very tricky. Unless I've missed something, we essentially
have to get assistance from the runtime linker and/or
duplicate some of its functionality. dlsym() et al aren't
enough.
2. Although we can imagine that glXGetProcAddress could query the
GLX encoder and all local drivers to compose a list of all
possible entry points, this isn't sufficient for GLU, because
GLU entry points are unknown to GLX and the drivers. This
means glXGetProcAddress still has to chase down GLU symbols in
the way mentioned in item #1.
3. We need to review the calling-sequence issue that David Blythe
raised. If any of the functions that could be dynamically
dispatched require callee-cleanup calling sequences, then
there is no way to support either a clean error return or
no-op behavior for such functions. (Calling them when they're
actually supported will still work, though.)
4. As Michael Gold mentioned to me a few weeks ago, all of the
context-independent glXGetProcAddress implementations
discussed so far require assembly-language implementations.
We should decide whether the lack of a portable sample
implementation is a problem.
Mostly my conclusions match the resolutions of issues in the latest
edition of the spec. I realize I haven't backed them up with a
convincing rationale, so feel free to ignore them :-), but since the
ARB meeting is coming up right away, I thought I'd mention them
anyway.
1. Getting ``correct'' behavior in the presence of
statically-linked, stripped executables looks really
difficult. This implies implementations might be practical
only for dynamically-dispatched entry points, even when some
functions are statically linked in an attempt to override
those of the DSO. Therefore we should not guarantee
glXGetProcAddress("foo")==&foo. (Too bad; I might have made
use of this invariant.)
2. Because the GLU has been treated as fundamentally separate
from core OpenGL and GLX, implementation concerns for the GLU
affect the design of *GetProcAddress. (In particular, the
dynamic dispatch mechanism we plan to use for the core isn't a
good match for a system with a separate GLU DSO.) I'd
recommend we take one of two actions:
(a) Change the implementations so that the GLU is
incorporated in libGL, and thus both version-control
and symbol lookup for GLU can be piggybacked on those
for libGL.
(b) Specify a separate gluGetProcAddress to handle the
(possibly unique) requirements of symbol lookup for
GLU.
3. Assuming we accept suggestion #1, it is practical for
glXGetProcAddress to return NULL (or some other error
indication) when asked to find the address of an unsupported
function. The incremental work required to do this is
probably negligible, no matter whether the returned pointers
are context dependent or context independent. I think it has
value for app developers.
Regards,
Allen
