On Tue, Apr 23, 2002 at 12:49:20AM +0100, Keith Whitwell wrote:
> Well, you're doing something you're not supposed to do & as a result
> glXGetProcAddress isn't working right.
>
> Do you really need to call your symbol glBegin? How about xyzBegin or
> similar?
I have managed to solve this problem (see below), but first I'll give some
background. I had a rather large chunk of OpenGL code from a non-Linux
system that made some assumptions about what extensions would be available
in libGL.so. It checked to make sure that the extensions were enabled in
the driver before calling them, but it still assumed that the linker would
be able to resolve them at load time. Since a number of these extensions
don't exist in Mesa, the program would compile just fine, but it would not
link.
I *really* did not want to have to make changes to the source code. It is
about 100,000 LOC, and changing the source with a bunch of ifdefs sounded
like way too much work. My initial attempt at working around this was to
write a script that would process glext.h and use the PFNGL* typedefs to
create a bunch of pointers-to-functions. It also generated a table of
structures that I would use with glXGetProcAddress to resolve the pointers.
struct gl_extension
{
/* Name of the function that is needed.
*/
const char * name;
/* Pointer to the pointer-to-function.
*/
void ** function;
};
A short stub routine would get called once at start up to fill in all of the
function pointers using glXGetProcAddress. Since all of the C files
included a header file that declared all of the extension functions as
pointer-to-function, the compiler would generate code to call it the right
way. If everything worked correctly, I would need to make no changes to the
100,000 lines of application code.
Everything did work correctly UNTIL it came time to resolve a function that
was exported by libGL.so. I believe the function that actually started the
whole mess was glTexImage3DEXT, but it could have just as easilly been any
of a number of functions. As near as I can tell, when ld.so loaded
libGL.so, it saw that glTexImage3DEXT was in address space already, so it
didn't bother to load it from the library. All references to
glTexImage3DEXT in the library were directed to the symbol in the
application. The end result being that glXGetProcAddress( "glTexImage3DEXT" )
returned a pointer to the address where I was going to store it!
I did find a very inelegant way to work around this (for those not
completely following, this is a work around to a work around *grin*).
Instead of having the script create a header file with the
pointers-to-functions having their actual OpenGL names, it prepends foo_ to
all of the names. glTexImage3DEXT becomes foo_glTexImage3DEXT. It then
generates a define to redirect the OpenGL name to the foo_ name.
#define glTexImage3DEXT foo_glTexImage3DEXT
Since this happens in the C preprocessor, ld.so never has any knowledge of
it. All it sees in the application is foo_glTexImage3DEXT, so it knows that
it still needs to resolve glTexImage3DEXT from libGL.so.
I *KNOW* that I cannot be the first person who has ever had to try and solve
this problem. The OpenGL developer FAQ provides some hints, but really only
gives enough information to get from an unlinkable application to an
unrunable application.
http://www.opengl.org/developers/faqs/technical/extensions.htm#0060
How have other people solved this? If there are some particularly good
sollutions out there, perhaps we could recommend that they be added to the
OpenGL developer FAQ. That sure would have saved me some trouble!
--
Tell that to the Marines!
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
