[patch] Use dlsym instead of glXGetProcAddress in xdriinfo

[Matthias Hopf]

On Nov 23, 05 07:27:14 -0800, Ian Romanick wrote:
> > I don't think using dlym is actually allowed, as the OpenGL calls are
> > not neccessarily expected to be exported (and can even be context
> > dependend).
> 
> No, no, no!!!  On GLX, function pointers are explicitly defined to be
> context independent.  The same is not true on WGL.  However, the pointer

Ok, took some time to finally re-read the extension, and *blush* you are
perfectly right. Seems that I've read something else and mixed that up.

Thanks for correcting me!

> returned by glXGetProcAddress for statically exported functions need not
> be the same as the statically exported address (which is what dlsym
> would return).  So 'glXGetProcAddressARB("glVertex3fv")' may not return
> the address of the static glVertex3fv function.

Still, I guess in this context both functions must finnally do the same
and the programmer must be able to mix them. Right?

> In general, you are correct that dlsym should not be used for this sort
> of thing.  This particular usage falls outside the range of "in
> general".  Using dlsym to get the address of an explicitly
> platform-dependent symbol is different than an application trying to
> access a platform-independent API entrypoint.

ACK

> > However, a valid solution used by most games is to dynamically load
> > libGL, and use dlsyn to get either glXGetProcAddress or
> > glXGetProcAddressARB, whatever is defined.
> 
> The Linux OpenGL ABI *requires* that glXGetProcAddressARB be statically
> exported by libGL (see section 3.6).

I know. It's just that the header files are not allowed to define a
prototype for this function, if they claim to be GLX 1.4 compatible
(which hasn't been released yet, and I don't know whether this
requirement has been released in the meantime. I hope so). At least some
time ago we stumbled over this problem (not with the Linux header files,
I think we used either NVIDIA's or even the official version), and
noticed that several engine designers had the same problem.

Thanks

Matthias

-- 
Matthias Hopf <mhopf at suse.de>       __        __   __
Maxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat at mshopf.de
Phone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de